Welcome

 ANP, Trenton, ME About this tide

Welcome to the offline version of XTide's support documents as of the date identified in this .chm's file name; e.g., XTide v2.x Help (bYYYYMMDD).chm

For the latest information on XTide, always visit https://flaterco.com/xtide/


Introduction and system requirements

Bald Head Cliff, Ogunquit, Maine, 1998-06-15

Introduction

XTide is a package that provides tide and current predictions in a wide variety of formats. Graphs, text listings, and calendars can be generated, or a tide clock can be provided on your desktop.

XTide can work with X-windows, plain text terminals, or the web. This is accomplished with three separate programs: the interactive interface (xtide), the non-interactive or command-line interface (tide), and the web interface (xttpd).

The algorithm that XTide uses to predict tides is the one used by the National Ocean Service in the U.S. It is significantly more accurate than the simple tide clocks that can be bought in novelty stores. However, it takes more to predict tides accurately than just a spiffy algorithm—you also need some special data for each and every location for which you want to predict tides. XTide reads these data from harmonics files.

Ultimately, XTide's predictions can only be as good as the available harmonics data. It is up to you to verify that the predictions for your locale match up acceptably well with the officially sanctioned ones.

  • Deviations of 1 minute from official predictions are typical for locations having the latest data.
  • Deviations of 20 minutes are typical for locations that are using obsolete data.
  • Much longer deviations indicate a problem.

The XTide software distribution resides at https://flaterco.com/xtide/files.html.

XTide and its documentation are maintained by David Flater (dave@flaterco.com).


News

XTide 2.15.2 (2019-02-24)

This fixes an SVG character escaping bug that caused the SVG outputs for some locations to have bad syntax. Get it from https://flaterco.com/xtide/files.html#xtide.

tideeditor-1.4.5 (2019-02-03)

Applied a patch from Egil Kvaleberg to correct inconsistent behavior in locales that use comma as decimal separator. Get it from https://flaterco.com/xtide/files.html#extras.

harmgen-3.1.3 (2019-02-02)

Fixed code rot: harmbase2 no longer has OIDs, so can't use OIDs in the insert statement that harmgen outputs. Available from https://flaterco.com/xtide/files.html#experts.

Data refresh 2018-12-27

Data refresh available from https://flaterco.com/xtide/files.html#harmonicsfiles.

A corresponding renovation of the harmonic constants management package is available from https://flaterco.com/xtide/files.html#experts.

congen-1.7 (2018-01-14)

Fixed race in parallel builds; updated congen_input.txt; added scripts XDO2Basic.rb and Compound2Basic.rb. Available from https://flaterco.com/xtide/files.html#experts.

End of maintenance for non-free data

For various reasons, I have ended maintenance of the non-free data set. Anyone interested in generating new harmonic constants from published data can find information and a list of data sources here.

Mailing list

There is an announce-only mailing list to which I send notices of each update to XTide or the harmonics data. You can subscribe or read the archives at http://ten.pairlist.net/mailman/listinfo/xtide-announce.

Please note: If an announcement to you gets bounced by your mail server, you fall off the list. Some long-time contributors have fallen off because, unbeknownst to them, their ISPs subscribed to a spam blackholing service that blackholed all pair.com-hosted domains after one of them sent out spam.

To do list

XTide

Scripts are out of date.

Possibly add hooks or scripts for easier Termux builds.

Upstream any harmless portability nits from XTideMac.

Make xttpd use https.

The XML parser should be bundled under the libxtide namespace but isn't.

Major things to do in XTide 3 if life turns out not to be too short after all:

  • Renovate programming practices again (exceptions, checked and const operations, strings).
  • On exceptions: get the application-specific error messages OUT of libxtide.
  • Move from Latin-1 to UTF-8 (requires libtcd revision).
  • Harmonize the globe location chooser with the way that Google Earth operates. Use OpenGL of course.
  • Find a way to put an end to the infinite number of customization settings for graph mode, such as by dumping ALL of the data, metadata, and events to a single-file format that an external graphing app will read.
  • Support Wayland in non-X11 mode.

tideEditor

Qt 5 migration is in process.

On Manjaro, you have to install the qt4 package, which is available but not installed by default. After running all normal updates, do sudo pacman ‑S qt4. Then, when configuring, specify CPPFLAGS=‑I/usr/include/qt4 and MOC=/usr/bin/moc‑qt4.

harmgen

It should be possible to link directly with liboctave to avoid the very inefficient conversion of input data from binary to text and back again that currently is done. However, this would be fixing something that is not broken, and is neither important nor urgent.

libtcd

Remember to update the version strings in the pre-generated DOS/tcd.h and VS/tcd.h files.

Remember to update the DOS and VS build instructions in the documentation and in VS/README.txt.

Incorporate notes and findings about the SP98 inference method from the flips investigation into the documentation somewhere.

Things to do in the next major revision, if there ever is one:

  • UTF-8.
  • Add header field to flag tides versus currents.
  • Add depth field for currents.
  • Get rid of internal state; fix inability to have more than one database open.
  • Remove gratuitous complexity in the encoding of speeds, equilibrium arguments, and node factors; make speeds 32-bit unsigned with no offset.
  • Possibly permit node factors to be specified for intervals shorter than 1 year and/or support apps that use libcongen to generate the node factors themselves.


License and disclaimer

NOTE. The license and disclaimer appearing below applies to the XTide program itself. For information about permissions on the harmonic constants, see https://flaterco.com/xtide/harmonics_boilerplate.txt.

XTide 2 Copyright © 1998 David Flater

This software is provided under the terms of the GNU General Public License, either version 3 of the License, or (at your option) any later version.

Although the package as a whole is GPL, some individual source files are public domain. Consult their header comments for details.

NOT FOR NAVIGATION

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. The author assumes no liability for damages arising from use of this program OR of any 'harmonics data' that might be distributed with it. For details, see the appended GNU General Public License.

(Accurate tide predictions can only be made if the 'harmonics data' for the relevant location are good. Unfortunately, the only way the maintainer of those data has of knowing when they are bad is when someone with access to authoritative tide predictions or observations reports a problem. You should not use this program or any data files that might be distributed with it if anyone or anything could come to harm as a result of an incorrect tide prediction. NOAA and similar agencies in other countries can provide you with certified tide predictions if that is what you need.)

XTide's predictions do not incorporate the effects of tropical storms, El Niño, seismic events, subsidence, uplift, or changes in global sea level.

The tide prediction algorithm used in this program was developed with United States Government funding, so no proprietary rights can be attached to it. For more information, refer to the following publications:

Manual of Harmonic Analysis and Prediction of Tides. Special Publication No. 98, Revised (1940) Edition (reprinted 1958 with corrections; reprinted again 1994). United States Government Printing Office, 1994.
Computer Applications to Tides in the National Ocean Survey. Supplement to Manual of Harmonic Analysis and Prediction of Tides (Special Publication No. 98). National Ocean Service, National Oceanic and Atmospheric Administration, U.S. Department of Commerce, January 1982.

GNU GENERAL PUBLIC LICENSE

Version 3, 29 June 2007

Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>

Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

Preamble

The GNU General Public License is a free, copyleft license for software and other kinds of works.

The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.

To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.

For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.

Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.

Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.

The precise terms and conditions for copying, distribution and modification follow.

TERMS AND CONDITIONS

0. Definitions.

“This License” refers to version 3 of the GNU General Public License.

“Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.

“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations.

To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.

A “covered work” means either the unmodified Program or a work based on the Program.

To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.

To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.

An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.

1. Source Code.

The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.

A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.

The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.

The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.

The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.

The Corresponding Source for a work in source code form is that same work.

2. Basic Permissions.

All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.

You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.

Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.

3. Protecting Users' Legal Rights From Anti-Circumvention Law.

No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.

When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.

4. Conveying Verbatim Copies.

You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.

You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.

5. Conveying Modified Source Versions.

You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:

  • a) The work must carry prominent notices stating that you modified it, and giving a relevant date.
  • b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.
  • c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
  • d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.

A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.

6. Conveying Non-Source Forms.

You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:

  • a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
  • b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
  • c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
  • d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
  • e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.

A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.

A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.

“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.

If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).

The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.

Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.

7. Additional Terms.

“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.

When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.

Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:

  • a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
  • b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
  • c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
  • d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
  • e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
  • f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.

All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.

If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.

Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.

8. Termination.

You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).

However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.

Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.

Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.

9. Acceptance Not Required for Having Copies.

You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.

10. Automatic Licensing of Downstream Recipients.

Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.

An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.

You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.

11. Patents.

A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's “contributor version”.

A contributor's “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.

Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.

In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.

If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.

If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.

A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.

Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.

12. No Surrender of Others' Freedom.

If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.

13. Use with the GNU Affero General Public License.

Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.

14. Revised Versions of this License.

The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.

If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.

Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.

15. Disclaimer of Warranty.

THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

16. Limitation of Liability.

IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

17. Interpretation of Sections 15 and 16.

If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.

END OF TERMS AND CONDITIONS

How to Apply These Terms to Your New Programs

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.

    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.

Also add information on how to contact you by electronic and paper mail.

If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode:

    <program>  Copyright (C) <year>  <name of author>
    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”.

You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see <http://www.gnu.org/licenses/>.

The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read <http://www.gnu.org/philosophy/why-not-lgpl.html>.


System requirements

Hardware

XTide uses less than 15 MB of memory for a typical interactive session. The base configuration for which XTide 2 was written was a 166 MHz Pentium PC with 32 MiB of RAM (circa 1997). XTide continues to be runnable on such a PC and on comparable non-PC hardware such as a Sun Sparcstation. Unfortunately, to build XTide comfortably with GCC now requires a minimum of 128 MB of memory.

Operating system

XTide is Unix software. It is intended to compile and run correctly on any reasonably modern version of Unix. However, I no longer have direct access to any flavor of Unix other than Linux, so I can only make portability fixes if and when issues are reported.

In order for tide predictions to have the correct Daylight Savings Time (Summer Time) adjustments, your platform must provide a sufficiently up-to-date version of the tz database. If your time zone database is obsolete, you may be able to upgrade it using the latest version from http://www.iana.org/time-zones or by installing an operating system patch.

Some non-Unix platforms have limited support:

  • All parts of XTide can be run under Windows using Cygwin.
  • The command-line client tide can be built and run natively on Android, Windows, and DOS. Android can furthermore run xttpd.
  • libxtide, a C++ library that provides all of the back-end functionality of XTide but not the user interface, can be built on Android, Windows, and DOS and used to develop new apps.
  • XTide has been ported to a variety of other operating systems with differing levels of success as detailed in the ports section.

Software

XTide is written in C++. GCC version 4.4 or newer should work.

You need bzip2, 7-Zip or some other archiver that supports the bzip2 format to uncompress the files. A list of libraries on which XTide is dependent is provided in the next section.

The interactive client requires that the Schumacher fonts be installed with X11. These fonts are always included with the X11 distribution, but their installation is frequently optional.


Assembly Required

ANP, Trenton, ME

Regardless of your general familiarity with computer programs, or the lack thereof, Open Source software requires the source files (e.g., written in C++) to first be compiled into an executable. For experienced XTide users and those familiar with Linux, the build process requires minimal effort while most Windows users that have never uttered the word sudo (say aloud: sue-dough) will discover their guided efforts to install XTide quite worthwhile.

Not interested in freshly building your own? XTide has been ported for you to other platforms though 1) may not be of even date with the current source files available from http://www.flaterco.com/xtide/files.html and 2) the alternative ports are supported by their respective maintainers and to whom support questions should be routed.


Installation Guide For New Users of XTide

VirtualBox Logo Users running the Microsoft Windows operating system (or Mac OS) and who wish to run XTide have, in addition to alternative installations, the option to build their own in a UNIX/ LINUX (*NIX) environment. The simplest way of creating that environment is by using a so-called virtual machine like Oracle's VirtualBox.

Oracle's virtualization product is freely available as Open Source Software under the terms of the GNU General Public License (GPL) version 2.

Ubuntu logo Once you've installed Oracle's VirtualBox, you can then install a guest operating system like Canonical's popular Ubuntu.

This Installation Guide For New Users of XTide was originally written for XTide v2.15.1. For the most recent release of XTide, be sure to check and see which version of XTide and its dependancies are current by visiting https://flaterco.com/xtide/files.html. This Installation Guide For New Users of XTide includes screen captures using VirtualBox v5.1.10 and Ubuntu v16.04 LTS. This guide does not include detailed instructions for installing VirtualBox, nor for installing Ubuntu as a plethora of such tutorials can readily be found online.

Need to update from an earlier version of XTide?

XTide 2.15.2 (libxtide.so.1.0.2) was made available on 20190224. Existing users of XTide 2.15.1 wishing to upgrade to v2.15.2 can do so by following the section below entitled Updating XTide.

Configure, Make and Make Install

If you're new to Linux and building a program from source files, there are generally three steps involved:

General Outline for Building and Installing a Program from Source Files
Step No. As normal user As Super User
1
./configure

This first step checks to see if the build environment is ready and will inform you if something is missing from your system before proceeding through the script completely uninterrupted.
2
make

This second step takes the instructions from the first step and builds the program to be installed on your system.
3
make install

The last step requires elevated privileges to install the program on the system and is conceptually similar to installing a program as Administrator under the Windows User Account Control schema.

All three steps are performed from the terminal (Ctrl+Alt+T) as more fully discussed in the proceeding sections.

Preparations

XTide's source files and the other library files on which XTide depends, should be downloaded first. Additionally, the basic Ubuntu installation may not have included other needed libraries and should also be downloaded. This is where the first step discussed above is quite handy by identifying any missing files from your system. These archived (compressed) source files and dependencies need to be downloaded and placed in an easy to locate folder.

Let's get organized - mkdir

terminal icon Make a new directory (folder) using the terminal (Ctrl+Alt+T) and the command mkdir as shown below in the Files (GUI file browser formerly known as Nautilus) browser window.

mkdir

terminal icon Combine commands in the terminal and download the wvs archive file into a folder by typing:

mkdir ~/XTide/wvs; cd ~/XTide/wvs; wget ftp://ftp.flaterco.com/xtide/wvs.tar.bz2

In the terminal, it would appear like this:

cd mkdir wget

terminal icon The downloaded wvs archive files will next need to be extracted into the ~/XTide/wvs folder by typing:

tar xvf wvs.tar.bz2

In the terminal, it would appear like this:

tar extract

The world vector shoreline data needs to be found by XTide when it presents the mapped locations of the tidal stations as either the flat map or the globe. The discrete placement of the wvs folder and its contents is arbitrary; wherever you place it, make note of it as it will need to be entered as a line in the /etc/environment file in a later step as described below. In the example above, the path would be fully written as: /home/kelly/XTide/wvs

terminal icon Supplemental Packages to ubuntu-16.04.1desktop-amd64.iso

It should be noted that this tutorial was written immediately after a fresh installation of the disk image ubuntu-16.04.1-desktop-amd64.iso (available here) and the installation of its updates. Before going further with the building and installation of the three remaining XTide dependencies; i.e., libtcd-2.2.7, xtide-2.15.1 and its harmonics file, the following packages will need to be installed. And because they have been packaged for us, their installation is quickly addressed by typing:

sudo apt-get install xorg-dev libxaw3dxft8-dev libpng-dev

XTide and its dependencies

From flaterco.com

  • ftp://ftp.flaterco.com/xtide/xtide-2.15.1.tar.bz2
  • ftp://ftp.flaterco.com/xtide/libtcd-2.2.7-r2.tar.bz2
  • ftp://ftp.flaterco.com/xtide/harmonics-dwf-20151227-free.tar.bz2 **
  • ftp://ftp.flaterco.com/xtide/wvs.tar.bz2 (N.B. - This should have already been done in the preceding section - Combine Commands)

N.B. - On 2018-03-23, the file hosting was migrated from ftp to https. For now, the files in https://flaterco.com/files/xtide/ are also available by anonymous FTP from ftp://ftp.flaterco.com/xtide/

** The harmonics file is date stamped with constants captured once per year shortly before year's end. In this example, December 27, 2015 is the date of the harmonics file. It does not include any new tide stations that may have been added, nor those which may have been removed subsequently and is why you should update this file once a year, generally after the first of the year. Accordingly, in the following procedures where this date stamped file is mentioned, substitute it with the most up to date harmonics file avialable from http://www.flaterco.com/xtide/files.html#harmonicsfiles .

Always check http://www.flaterco.com/xtide/files.html for the latest XTide files and any updated links to its dependencies as this .chm file may not be updated as frequently.

terminal icon Out of the 4 files listed above, you should now have only 3 left to download into the ~/XTide folder by typing:

wget ftp://ftp.flaterco.com/xtide/libtcd-2.2.7-r2.tar.bz2

wget ftp://ftp.flaterco.com/xtide/xtide-2.15.1.tar.bz2

wget ftp://ftp.flaterco.com/xtide/harmonics-dwf-20151227-free.tar.bz2

Alternatively to typing three separate lines and downloading these files individually, you could combine all three URLs into a single line in the terminal and download the files consecutively, it would appear like this:

wget 3 files

terminal icon Extract all archives into the ~/XTide folder at once by typing:

find -maxdepth 1 -iname \*.tar.* -exec tar -xvf {} \;

In the terminal, it would appear like this:

mass extraction2

Preliminary Chores

The manually downloaded and extracted library dependencies need to be taken care of next.

terminal icon Make a new folder and change its permissions by typing:

sudo mkdir /usr/local/share/xtide

sudo chmod 755 /usr/local/share/xtide

In the terminal, it would appear like this:

terminal icon From the folder where the harmonics file was originally extracted, change the harmonics file's permissions, move it and then check it by typing:

sudo chmod 644 harmonics-dwf-20151227-free.tcd

sudo mv harmonics-dwf-20151227-free.tcd /usr/local/share/xtide

cd /usr/local/share/xtide; ls

In the terminal, it would appear like this:

chmod mv ls

As previously mentioned, harmonics files are updated annually, generally at the end of December and can be found at: http://www.flaterco.com/xtide/files.html#harmonicsfiles. Once that you have previously configured, made and installed XTide, updating the harmonics file is simple. To update the harmonics file on your system, follow the same procedures outlined above for its change mode (chmod) settings and placement into the specified directory using the new harmonics file before deleting the old file. Updating just the harmonics file doesn't require any further action.

terminal icon From the ~/XTide/libtcd-2.2.7 folder, configure, make and as Super User make install the libtcd dependencies by typing:

./configure

make

sudo make install

In the terminal, it would appear like this:

libtcd configure make sudo make install

gedit terminal icon Ensure that XTide knows where to find things

If the file /etc/environment doesn't already exist, it will be created by doing the following; otherwise, append the /etc/environment file as Super User by typing:

sudo gedit /etc/environment

Append the file with these two lines of text, Save and close:

HFILE_PATH=/usr/local/share/xtide
WVS_DIR=/home/kelly/XTide/wvs

In the terminal, it would appear like this:

gedit environment

Building XTide

terminal icon From the ~/XTide/xtide-2.15.1 folder, configure, make and as Super User make install XTide by typing:

./configure

make -j 8

sudo make install

In the terminal, it would appear like this:

xtide configure make sudo make install

That's it - you're done building XTide from source files! Congratulations! But before you run XTide for the first time, reboot your system to allow your system's dynamic linker to finish doing its job in linking the various libraries.

terminal icon From any folder, reboot your system by typing:

sudo reboot

First Run of XTide

terminal icon Launch XTide from any folder by typing:

xtide

In the terminal, it would appear like this:

Globe and List intro

Troubleshooting

Please refer to the troubleshooting section of the installation instructions. If your error is not discussed there, please email dave@flaterco.com for assistance.

Updating XTide

XTide 2.15.2 (libxtide.so.1.0.2) was made available on 20190224. Existing users of XTide 2.15.1 wishing to upgrade to v2.15.2 can do so by following these directions while noting that this Updating XTide section of the Installation Guide For New Users of XTide includes screen captures using VirtualBox v5.2.26 and Ubuntu v18.04 LTS.

Question: Must the entire build process (less dependencies already on hand from a previous build) be exactly repeated step by step?

Answer: Since the build scripts have been updated, it will be best to build xtide from scratch but you don't need to rebuild libtcd, etc.

Files needed when updating XTide and its dependencies

From flaterco.com

  • https://flaterco.com/files/xtide/xtide-2.15.2.tar.bz2
  • https://flaterco.com/files/xtide/harmonics-dwf-20181227-free.tar.bz2

N.B. - On 2018-03-23, the file hosting was migrated from ftp to https.

** The harmonics file is date stamped with constants captured once per year shortly before year's end. In this example, December 27, 2018 is the date of the harmonics file. It does not include any new tide stations that may have been added since, nor those which may have been removed subsequently and is why you should update this file once a year, generally after the first of the year. Accordingly, in the following procedures where this date stamped file is mentioned, substitute it with the most up to date harmonics file avialable from https://www.flaterco.com/xtide/files.html#harmonicsfiles .

Always check https://www.flaterco.com/xtide/files.html for the latest XTide files and any updated links to its dependencies as this .chm file may not be updated as frequently.

terminal icon Download into the ~/XTide folder by typing:

wget https://flaterco.com/files/xtide/xtide-2.15.2.tar.bz2

wget https://flaterco.com/files/xtide/harmonics-dwf-20181227-free.tar.bz2

Alternatively to typing two separate lines and downloading these files individually, you could combine them into a single line in the terminal and download the files consecutively, and would appear like this:

wget 2 files

terminal icon Extract the new version of xtide from the archive into the ~/XTide folder by typing:

tar -xvf xtide-2.15.2.tar.bz2

terminal icon From the ~/XTide folder, extract the new version of the harmonics file from the archive by typing:

tar -xvf harmonics-dwf-20181227-free.tar.bz2

terminal icon From the folder where the new harmonics file was extracted, change the harmonics file's permissions, move it and then check that it correctly arrived by typing:

sudo chmod 644 harmonics-dwf-20181227-free.tcd

sudo mv harmonics-dwf-20181227-free.tcd /usr/local/share/xtide

cd /usr/local/share/xtide; ls

chmod mv ls

terminal icon Remove (delete) the old harmonics file from the /usr/local/share/xtide folder by typing:

sudo rm harmonics-dwf-20151227-free.tar.bz2

rm old harmonics

gedit terminal icon Ensure that XTide knows where to find things

Even though you might have already addressed this matter once, depending upon your system, you may need to do this again in order to make sure XTide can find the new harmonics file and the world vector shoreline files.

If the file /etc/environment doesn't already exist, it will be created by doing the following; otherwise, append the /etc/environment file as Super User by typing:

sudo gedit /etc/environment

Append the file with these two lines of text, Save and close:

HFILE_PATH=/usr/local/share/xtide
WVS_DIR=/home/kelly/XTide/wvs

In the terminal, it would appear like this:

gedit environment

Building XTide

terminal icon From the ~/XTide/xtide-2.15.2 folder, configure, make and as Super User, make install XTide by typing:

./configure

make -j 8

sudo make install

configure make install

That's it - you're done updating and building XTide from source files! Congratulations! But before you run XTide, reboot your system to allow your system's dynamic linker to finish doing its job in linking the various libraries.

terminal icon From any folder, reboot your system by typing:

sudo reboot

terminal icon Check XTide version from any folder by typing:

xtide -v

Troubleshooting

Please refer to the troubleshooting section of the installation instructions. If your error is not discussed there, please email dave@flaterco.com for assistance.

Question: Once xtide has been built and installed, which files can be removed, and which must remain?

Answer: Assuming that you want to install it to /usr/local,
- Configure with --prefix=/usr/local
- make -j 8
- make install

Then everything that must remain will be installed in /usr/local and you can delete the source / build dir.

DWF


Installation instructions for supported platforms

Assumptions

These installation instructions assume basic familiarity with the Unix command line and that you are building from sources obtained from https://flaterco.com/xtide/files.html. If this is a big ask, there are other options:

  • Binary packages for some platforms are available under contrib files. (Thanks to the relevant package maintainers.) However, you need to be careful about out-of-date packages.
  • Kelly Bellis wrote detailed, step-by-step instructions from the perspective of a Windows user running Ubuntu in a virtual machine. The merged documentation (this online documentation plus Mr. Bellis' value added) is provided in a .chm file (Microsoft Compiled HTML Help). Last rev 20170105 for XTide 2.15.1.

Mandatory library dependencies

The "tested" versions of libraries cited below are merely the versions that were demonstrated to work at the time of the last XTide release, for information in case a compatibility issue arises.

In addition to the minimal set of X11 libraries that pretty much everyone has, you need the following libraries:

  • libXpm (tested ver. 3.5.11)
  • zlib (a.k.a. libz), prerequisite of libpng (tested ver. 1.2.8)
  • libpng (tested ver. 1.6.21)
  • libtcd (tested ver. 2.2.7-r2)

Debian/Ubuntu users can install the dependencies by doing this:
sudo apt-get install xorg-dev libxaw3dxft8-dev libpng-dev
and then building libtcd from source (configure; make; sudo make install).

The interactive client requires that the Schumacher fonts be installed with X11. These fonts are always included with the X11 distribution, but their installation is frequently optional.

tide and xttpd can be compiled in the absence of X11 libraries and libXpm. However, you still need the other stuff.

Optional libraries

The configure script will look for Xaw3dXft, Xaw3d, or Xaw, in that order.

Plain Athena Widgets (Xaw) (tested ver. 1.0.12 / X11R7.7) can be forced using ––disable-3d.
Xaw3d (tested ver. 1.6.2) is a fork from an old version of Athena Widgets that offers improved scrollbars and a different look for buttons. Versions 1.6 through 1.6.2 appeared in Q1 2012; prior to that, version 1.5E had been frozen since 2003. Some issues that were subsequently fixed in Athena Widgets, such as long menus running off the screen, were fixed differently in Xaw3d. (This affects the Set Time dialog, where the list of years to choose from can be quite long.)

Xaw3dXft is a fork from Xaw3d 1.5E that uses FreeType fonts. The primary site is http://sourceforge.net/projects/sf-xpaint/files/libxaw3dxft/. If font quality is important, Xaw3dXft is the best choice. It also fixes the problem with long menus in the Set Time dialog.

Xaw3dXft ver. 1.6.2d made breaking changes to the API. XTide 2.15 will work with 1.6.2d but no earlier version. XTide 2.14 works with several earlier versions but fails to build with 1.6.2d.

I recommend configuring Xaw3dXft with the following options: --enable-internationalization --enable-multiplane-bitmaps --enable-gray-stipples --enable-arrow-scrollbars

XTide will link with libgps if a compatible version is found on the system (tested ver. 3.16). If a GPS is present and working, XTide will zoom in on your current location automatically.

XTide will link with libdstr if a compatible version is found on the system (tested ver. 1.0). If no compatible libdstr is present, a local copy of Dstr 1.0 will be rolled into libxtide.

Downloading

Mandatory: You need the XTide source code distribution, available in bzipped tar format at https://flaterco.com/xtide/files.html#xtide.

Mandatory: You need at least one harmonics file. Harmonics files contain the data that are required for XTide to predict tides for different locations. Harmonics files are available at https://flaterco.com/xtide/files.html#harmonicsfiles.

Optional: If you want to enable XTide to draw coastlines on the map, you will also have to download the World Vector Shoreline (WVS) files, which are available in bzipped tar format at https://flaterco.com/xtide/files.html#WVS.

Installing a harmonics file

You will download a file with a name similar to harmonics-dwf-YYYYMMDD-free.tar.bz2. With GNU tar, you can unpack it as follows:

tar xvf harmonics-dwf-YYYYMMDD-free.tar.bz2

With another tar that does not include builtin support for bzip2, you need to do this instead:

bzip2 -dc harmonics-dwf-YYYYMMDD-free.tar.bz2 | tar xvf -

Unpack the archive in a temporary directory, then move the TCD file to a permanent location, e.g., /usr/local/share/xtide, and make it world readable:

mkdir /usr/local/share/xtide
chmod 755 /usr/local/share/xtide
chmod 644 harmonics-dwf-YYYYMMDD-free.tcd
mv harmonics-dwf-YYYYMMDD-free.tcd /usr/local/share/xtide

The tar file also includes a change log and the disclaimers and terms applying to the data.

Installing the World Vector Shoreline files (optional)

  1. Create a directory to contain the WVS files.
  2. Change your current working directory to that directory.
  3. Unpack the tar file in that directory.

Under Linux and any other system with GNU tar:

tar xvf wvs.tar.bz2

Elsewhere:

bzip2 -dc wvs.tar.bz2 | tar xvf -

Unpacking the sources

Under Linux and any other system with GNU tar:

tar xvf xtide-2.xyz.tar.bz2

Elsewhere:

bzip2 -dc xtide-2.xyz.tar.bz2 | tar xvf -

Configuring

I. Specify the location of the harmonics file(s)

There are two ways to do this.

  1. The first way is by setting the environment variable HFILE_PATH.

    export HFILE_PATH=/usr/local/share/xtide/harmonics.tcd

    In the event that you have more than one harmonics file that you wish to use simultaneously, list them separated by colons.

    export HFILE_PATH=/usr/local/share/xtide/harmonics-free.tcd:/usr/local/share/xtide/harmonics-nonfree.tcd

    Alternately, make sure that they are by themselves in a special directory and specify that directory as the value of HFILE_PATH. If an element of HFILE_PATH is a directory, XTide will attempt to load every file in that directory (so be sure that they are all harmonics files!)

    If you are installing as root, then it is recommended that you add this definition to a system-wide script such as /etc/profile if you have one. In Debian/Ubuntu, system-wide environment variables can be added to /etc/environment.

  2. The other way is by creating the file /etc/xtide.conf. The environment variable, if set, takes precedence over the config file.

    If a configuration file is used, the first line should consist of the value that would be assigned to HFILE_PATH:

    /usr/local/share/xtide/harmonics-free.tcd:/usr/local/share/xtide/harmonics-nonfree.tcd

II. Specify the location of the World Vector Shoreline files (optional)

Either set the environment variable WVS_DIR to the name of that directory or supply the directory name as the second line of the configuration file /etc/xtide.conf.

III. Run the configure script

bash-3.1$ ./configure

XTide is packaged with the popular and portable GNU automake, so all usual GNU tricks should work. Help on configuration options can be found in the CONFIGURE-HELP file or obtained by entering ./configure --help.

The web server xttpd is not necessary to use tide or xtide, so most users needn't worry about it. However, if you plan to run it, there is additional configuration at this point.

(New in XTide 2.15) If your system uses systemd instead of init, you must configure with --enable-systemd to be able to run xttpd as a systemd service.

To change the user and/or group under which xttpd tries to run (the defaults are nobody/nobody), provide the options --with-xttpd-user=user and/or --with-xttpd-group=group to configure. If you want to run xttpd but you don't have root, you will have to set these to your own username and the name of some group to which you belong.

bash-3.1$ ./configure --with-xttpd-user=xttpd --with-xttpd-group==xttpd

You can also set the webmaster address for xttpd this way.

bash-3.1$ ./configure --with-webmaster="somebody@somewhere.else"

IV. Other optional and alternative configurables

--enable-time-workaround | Work around Y2038 problem; disable time zones. See Appendix A — Historical predictions and Y2038 compliance.
--enable-gnu-attributes | Use with g++ –Wall –Wextra to make warnings smarter.
--enable-semicolon-pathsep | Use ; instead of : to separate names in HFILE_PATH (good idea if they begin with C:\).
--enable-local-files | Locate xtide.conf, .xtide.xml, and .disableXTidedisclaimer files in current working directory.
--disable-3d | Use only genuine Athena Widgets.
--enable-lm_hard | Link with libm_hard instead of libm (for ARM Android).
--enable-moon-age | (Experimental) Replace calendar mode moon phase column with moon age.

You can change the compile-time defaults (colors, etc.) set in libxtide/config.hh if you so choose. However, the easiest way to set all of those things is with the control panel in the interactive XTide program.

The e-mail address for feedback in xttpd can also be changed by setting the environment variable XTTPD_FEEDBACK, in lieu of the configure option mentioned above.

Compiling and installing binaries

On Slackware:

$ make
$ su
# make install

On Debian/Ubuntu:

$ make
$ sudo make install

(With GNU make you can say make -j 8 to run 8 compiles in parallel if you want to speed it up.)

Systemd integration (XTide 2.15)

If xttpd was built with --enable-systemd, additional steps are needed to complete the installation.

  • make install-systemd will install xttpd.socket and xttpd.service into /lib/systemd/system.
  • If a port or address other than the default port 80 is to be used, edit /lib/systemd/system/xttpd.socket per systemd documentation.
  • If you want to provide the environment variables HFILE_PATH or XTTPD_FEEDBACK to xttpd, create the environment file /etc/sysconfig/xttpd per systemd documentation. If necessary, the path /etc/sysconfig/xttpd can be changed by editing xttpd.service, or the environment variables can be specified directly therein using Environment= instead of EnvironmentFile=.
  • make enable-systemd does the following final steps:
    • systemctl enable xttpd.socket xttpd.service
    • systemctl start xttpd.socket xttpd.service
  • If something goes wrong, make barf-systemd will dump the log for inspection (journalctl -b -p debug --no-pager).

Special cases

Don't have X11

If you don't have any version of X11 installed and just want to compile xttpd or tide, generate a Makefile using ./configure --without-x.

Mac OS X

2016-01: New maintainer David Strubbe reports that working, up-to-date build scripts are available from MacPorts.

Android

2018-10: Paul Poffenberger reported that XTide built "almost" out of the box using the tools available from Termux. Linux software is expected to need patching when it is built for Termux.

The XTide distribution does not provide a complete native Android app, but the basis for such an app, libxtide, can be built using the NDK. An example script for cross-compiling libpng, libtcd, libxtide, tide, and xttpd for Android on x86 or x86_64 Linux is in the XTide distribution as scripts/Android/build.sh. App developers can follow the example of MX Tides to add a JNI layer and GUI.

The tide and xttpd binaries produced by build.sh can be run from a shell prompt on a rooted device. Pointing a web browser at xttpd on the loopback address (http://127.0.0.1/) is a quick and dirty way to get a GUI. (Change for XTide 2.15: Android's xttpd now runs in the terminal instead of forking into the background, but otherwise works normally.)

Cygwin

XTide can be compiled and run using Cygwin, which is an emulated Unix environment for Windows that is free for typical non-commercial users. The Cygwin distribution and its full license terms are available from http://www.cygwin.com/.

Cygwin packages are all versioned separately, so there is no baseline "Cygwin version" against which to test XTide. Testing was most recently performed with XTide 2.15 using the collection of packages that was current as of 2016-01-23. As of then, the quirks apparent after brief testing were as follows:

  1. Had to specify LDFLAGS="-L/usr/local/lib" explicitly.
  2. If only building certain of the programs, you must type (e.g.) 'make tide.exe' instead of 'make tide'. 'make tide' causes the automake-generated makefile to do something silly.

DOS + DJGPP

[A prebuilt DOS binary for the command-line client is available in https://flaterco.com/xtide/files.html#contrib. It is usable in a DOS box under any 32-bit version of Windows and in DOSBox under 64-bit Windows.]

Don't laugh: the DOS binary works better under Windows than the native Windows one does.

A DOS binary for the command-line client tide can be built using DJGPP. The following instructions were last validated on 2016-01-25 with XTide 2.15 and DJGPP 2.05.

First things first

If using hard-core DOS, both a Long File Name (LFN) driver and a DPMI provider must be installed. Recommended:

  • doslfn from http://www.freedos.org/software/?prog=doslfn: LH DOSLFNMS.COM in AUTOEXEC.BAT.
  • The csdpmi7b.zip binaries from DJGPP's current/v2misc: add to PATH.

If using a DOS box (CMD.EXE) in a 32-bit version of Windows, LFN and DPMI should just work.

Unzipping

When unpacking zip files, use the unzip32.exe that is distributed with DJGPP to prevent file names from getting broken.

File names on NTFS must be created in the DOS namespace. Linux ntfs-3g doesn't do that. Similarly, the LFN implementation in Linux vfat is not entirely compatible with doslfn. It only works reliably if you mount the vfat partition with the option shortname=winnt.

Environment

For the validation build, the following DJGPP files were installed (unzipped in C:\DJGPP):

-rw-r--r--  1 dave users  8842737 Jan 22 17:34 bnu2251br3.zip
-rw-r--r--  1 dave users    71339 Jan 22 17:36 csdpmi7b.zip
-rw-r--r--  1 dave users  2509574 Jan 22 17:32 djdev205.zip
-rw-r--r--  1 dave users   603760 Jan 22 17:32 djtzn205.zip
-rw-r--r--  1 dave users 28597989 Jan 22 17:39 gcc530b.zip
-rw-r--r--  1 dave users 13008311 Jan 22 17:38 gpp530b.zip
-rw-r--r--  1 dave users  8391218 Jan 22 17:37 gtxt192b.zip
-rw-r--r--  1 dave users   405500 Jan 22 17:35 mak41br2.zip
-rw-r--r--  1 dave users  1293982 Jan 22 17:37 png1610b.zip
-rw-r--r--  1 dave users   194774 Jan 22 17:37 zlib128br2.zip

Environment variables:

SET PATH=C:\DJGPP\BIN;%PATH%
SET DJGPP=C:\DJGPP\DJGPP.ENV
SET TZ=:America/New_York

The environment variable TZ should be set to the zoneinfo identifier that is appropriate for your system clock. For example,

      SET TZ=:America/New_York
  or  SET TZ=:America/Los_Angeles
  or  SET TZ=:UTC
If this is not done, predictions will still be technically correct, but XTide will have the wrong idea of the current time when deciding what range of predictions to generate.

Dependencies

  • Prebuilt libraries for libpng and zlib both are available in the current/v2tk collection of the DJGPP archive (png*b*.zip and zlib*b*.zip).
  • Follow the instructions to build libtcd for DOS.

Building tide

  1. Ensure that scripts/DOS/Makefile.dj2 contains the correct path to the libtcd build directory.
  2. Do make -f scripts\DOS\Makefile.dj2.

The following behaviors will differ from the default Unix behaviors:

  • File names in the environment variable HFILE_PATH or the configuration file xtide.conf should be separated by semicolons instead of colons.
  • The optional xtide.conf, .xtide.xml, and .disableXTidedisclaimer configuration files should go in the current working directory. Not in PATH folders, not in the directory where the tide.exe executable is.
  • Text output is rendered in the DOS/Windows default codeset (CP437).
  • If output is redirected with >, LF to CR/LF translation is done. If output is redirected with –o, it is not. So to save output to a file, you have to use > for text formats, –o for PNG format. (Also be aware that –o will append to an existing file, rather than overwrite it.)

Windows + Visual Studio

[A prebuilt Windows binary for the command-line client is available in https://flaterco.com/xtide/files.html#contrib. It still runs in a DOS box, but is compatible with 64-bit Windows.]

When built with Visual Studio, XTide has to use an undesirable workaround for the absence of the Time Zone Database, and the resulting binary might not run on a different version of Windows. On 32-bit Windows, the DOS+DJGPP build is simply better. On 32- or 64-bit Windows, best results are obtained using Cygwin or a Linux VM.

The following instructions were last validated on 2016-01-25 with XTide 2.15 and Visual Studio Community 2015 with Update 1 under Windows 10 64-bit.

For Windows and Visual Studio, a script that builds zlib, libpng, libtcd, libxtide, and finally tide is available in the XTide distribution as scripts\VS\build.bat.

  1. Do [Windows Logo Thingy Formerly Known as Start Menu] → All Apps → Visual Studio 2015 (folder) → VS2015 x64 Native Tools Command Prompt. To prevent inexplicable file system permissions problems, right click it and run as Administrator. (Ha ha... That was a little Windows in-joke. Now that we have UAC, the only way to prevent inexplicable file system permissions problems is to use a FAT32 file system.)
  2. Unpack the zlib, libpng, libtcd, and XTide distributions under the current working directory.
  3. Copy xtide...\scripts\VS\build.bat to the working directory and edit it so that the version numbers specified at the top agree with what you have.
  4. build

As configured, the following behaviors will differ from the default Unix behaviors:

  • File names in the environment variable HFILE_PATH or the configuration file xtide.conf should be separated by semicolons instead of colons.
  • The optional xtide.conf, .xtide.xml, and .disableXTidedisclaimer configuration files should go in the current working directory. Not in PATH folders, not in the directory where the tide.exe executable is.
  • Because the Microsoft Visual Studio runtime doesn't support the zoneinfo database natively, you will get the message "XTide Warning: Using obsolete time zone database. Summer Time (Daylight Savings Time) adjustments will not be done for some locations."
  • Although the program successfully changes the codeset from CP437 to ISO-8859-1 when it runs, the DOS box reverts to CP437 as soon as the program exits, so text output that is saved to a file and then TYPEd at the command prompt will display incorrectly. The saved output is in the character set ISO-8859-1 and will display correctly in a web browser or editor.
  • If output is redirected with >, LF to CR/LF translation is done. If output is redirected with –o, it is not. So to save output to a file, you have to use > for text formats, –o for PNG format. (Also be aware that –o will append to an existing file, rather than overwrite it.)

For example, you could put the following in an xtide.conf file in the current working directory:

C:\Documents and Settings\Mumble\Foo\harmonics-free.tcd;C:\Documents and Settings\Mumble\Foo\harmonics-nonfree.tcd

CPU-constrained platforms

There are some CPU bottlenecks that are observable only on very old hardware. Real time estimates in the following are from a 166 MHz Pentium PC:

  • Updating the map in the location chooser takes between 0 and 20 seconds depending on how much of the world has to be redrawn. To avoid the lag when zoomed out, don't install the optional World Vector Shoreline database.
  • On the first run, libXaw3dXft bogs down for minutes trying to process exposure events on the long text of the disclaimer window. Since the disclaimer is normally read once and then disabled for future runs, one can either put up with it that one time or avoid the problem by building with libXaw3d or libXaw instead of libXaw3dXft.
  • Redrawing a default-sized tide graph takes about 1 second, which seems slow when one is scrolling forward or backward. Graph drawing is faster if an 8-bit display mode (PseudoColor visual) is used, but anti-aliasing and transparency are available only in true color modes.

The –aa setting that formerly could be used to speed up drawing on true color displays by disabling anti-aliasing was retired in XTide version 2.12.

Troubleshooting

Q: XTide compiles, but when I try to run it I get an error like the following about libtcd, libdstr, or libxtide:

error while loading shared libraries: libtcd.so.0: cannot open shared object file: No such file or directory

A: This happens when g++ found the shared library but your dynamic linker didn't. There are several possible fixes.

First, try running ldconfig as root (sudo ldconfig on Debian-like distros). This will fix the problem if the dynamic linker has a stale cache of the directory to which the libraries were installed. But if the libraries were installed to a directory that is not in the dynamic linker's search path, it won't make any difference.

If the libraries were installed to a nonstandard directory, the least invasive fix is to add that directory to the environment variable LD_LIBRARY_PATH. For example, if you find the library in /usr/local/lib, you would add this to your .bashrc (if using bash):

export LD_LIBRARY_PATH=/usr/local/lib
Or you would add this to your .cshrc (if using csh or tcsh):
setenv LD_LIBRARY_PATH /usr/local/lib

An alternative is to hard-code the directory into the executable using magic GNU linker switches: configure with LDFLAGS="–Wl,–rpath,/usr/local/lib" and rebuild XTide.

Another alternative is to edit the system configuration to add the nonstandard directory to the dynamic linker's search path. On Slackware, you just add the directory to /etc/ld.so.conf. Debian/Ubuntu prefer to add files in the subdirectory /etc/ld.so.conf.d. After making the change, run ldconfig again to update the cache.

Finally, if all else fails, you could link statically with the missing libraries.

Q: When compiling XTide, I get thousands of warnings of the form "warning: 'auto_ptr' is deprecated".

A: To suppress these nuisance warnings in GCC, use CPPFLAGS="–Wno-deprecated-declarations" or upgrade to GCC 4.6 or newer.

Q: When compiling XTide, I get an error involving xml-something or lex.xml.c.

A: Do make xmlclean and then try again.

Q: Using a DJGPP-built tide program in a DOS box in a 32-bit version of Windows, I get

harmonics.tcd: No such file or directory (ENOENT).
But the file is THERE!

A: When you do dir /X, you should see this:

  12/24/2012  03:15 PM         1,937,557 HARMON~1.TCD harmonics.tcd
If it says harmonics.tcd but not also HARMON~1.TCD, then the file was created in the wrong namespace. Recreate the file in a DOS box and confirm that HARMON~1.TCD then appears with dir /X.

Q: Using a DJGPP-built tide program in a DOS box in a 32-bit version of Windows, I get "Your platform appears to have broken time zone support. You need to get the DJGPP zoneinfo package and unpack it in C:\DJGPP." But C:\DJGPP\zoneinfo is THERE!

A:

  • To avoid namespace problems, unpack djtzn205.zip using DJGPP's unzip32.exe in a DOS box.
  • Ensure that DJGPP.ENV is installed in C:\DJGPP.
  • Ensure that the environment variable DJGPP is set to C:\DJGPP\DJGPP.ENV.

Q: DOS again... I unzipped the files under Linux into a vfat (FAT) file system, and now I've got problems in DOS like missing header file, broken time zones....

A: Yup. There's something incompatible in the LFN implementations. Don't ask me why, but this only works reliably if you mount the vfat partition with the option shortname=winnt.


Quick install instructions

  1. XTide 2 is Copyright (C) 1998 by David Flater, comes with absolutely no warranty, and is provided under the GNU General Public License. See the verbose documentation for all of the relevant disclaimers.
  2. XTide 2 requires:
    • libXpm
    • libpng
    • zlib (a.k.a. libz)
    • libtcd
  3. You must download at least one harmonics file. See https://flaterco.com/xtide/files.html#harmonicsfiles.
  4. You must set the environment variable HFILE_PATH to point to the harmonics files that you downloaded. Example:
    export HFILE_PATH=/usr/local/share/xtide/harmonics-free.tcd:/usr/local/share/xtide/harmonics-nonfree.tcd
  5. ./configure; make
  6. You should now have three binaries:
    • xtide, the interactive X-windows client
    • tide, the non-interactive TTY client
    • xttpd, the web server
  7. The X-windows client is easy to use. Go for it.
  8. tide does a few things that xtide doesn't do. Run it with nothing on the command line and read the usage info.
  9. xttpd is a self-contained web server. su root, fire it up and browse away. If it doesn't run, check your logs for errors and see https://flaterco.com/xtide/installation.html for configuration help.


Available ports for unsupported platforms

Available ports (and non-ports) for unsupported platforms

If a program is derived from XTide source code, I call it a port, even if there are significant changes, code added and code deleted. If a program contains no XTide source code but can use the same harmonics files that some version of XTide did, I call it a non-port. These are only listed if there is no good port to a given platform. This is not an attempt to track all tide-predicting software, only that with some commonality with XTide. Better software having nothing to do with XTide may be available, but is not listed here.

These programs are all maintained by different people. They may be significantly different from XTide 2 as documented here. If you have problems with a port or non-port, please contact the correct maintainer. I cannot help with anything but the canonical Unix distribution.

Android

Android screenshot

2018-10: Paul Poffenberger reported that XTide built "almost" out of the box using the tools available from Termux. Linux software is expected to need patching when it is built for Termux.

2015-01: Will Kamp produced a GPL port of XTide 2.14 to Android. The libxtide bit is separate from the user interface, and although it is close to stock it was rearranged somehow to work with the Android NDK build system. Source code is available at the preceding links; the MX Tides app is available from Google Play.

iOS / watchOS

iPhone screenshot

2017-01: Lee Ann Rucker did a nativized port to iOS, watchOS, and OS X using Cocoa and Objective-C++. The free app for iPhone, iPad, and Apple Watch is available at https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=1191127595 with sources at https://github.com/lrucker1/XTideMac.

Apple Watch screenshot

Older iOS ports:

  • Will Kamp, iOS version of MX Tides, port of XTide 2.?? in 2013 (free app, free sources).
  • Selene Associates LLC, port of XTide 2.12.1 to iOS (phone or tablet), called EyeTide Tide Watch ($ app, free sources).
  • Michael Parlee, port of XTide 2.10 to the iPhone, called ShralpTide2 ($ app, free sources). There was an older ShralpTide port based on XTide 1.6.2.

Mac

You don't need to use a port: See the installation instructions for details.

Mac screenshot 2017-01: The free Mac app for Lee Ann Rucker's nativized port is available at https://itunes.apple.com/WebObjects/MZStore.woa/wa/viewSoftware?id=1170393977 with sources at https://github.com/lrucker1/XTideMac.

Microsoft Windows

You don't need to use a port: XTide can be compiled and run using Cygwin, which is an emulated Unix environment for Windows that is free for typical non-commercial users. The Cygwin distribution and its full license terms are available from http://www.cygwin.com/. Please refer to the Installation section for special instructions about using XTide under Cygwin. Alternately, you could run a Linux virtual machine.

Native DOS and Windows binaries for the command-line client tide are available under contrib files and can be built as described in the Installation section.

The following native ports of the graphical client were done:

  • WTides by Phil Thornton, was forked from XTide 2 in the GPLv2 days. A "nagware" binary is available for downloading. Formerly, there was a fee to obtain the source code. As of 2016-01, quoted from here: "To exercise this right, please email me, and I shall then immediately send you a link to the latest source code on Dropbox. I have had to remove the source code from this website for lack of space." 🙄
  • "WXTide32" by Mike Hopper, was based on XTide 1.6.2 but includes its own location chooser. It works under Windows 95 or Windows NT. It has a web page at http://www.wxtide32.com/.
  • "WTide16" and "WTide32" by Paul C. Roberts, was based on XTide 1.3. It works under Windows 3.1 or Windows 95. It used to be at ftp://ftp.demon.co.uk/pub/ibmpc/win3/apps/wtide (link broken as of 2011-08-28).

R

rtide

2016-07: R is not an OS platform but a software environment for statistical computing and graphics. Joe Thorley and Luke Miller have produced rtide based on XTide's sources and harmonics data and made it available under GPL3. It is hosted at https://github.com/poissonconsulting/rtide.

Maemo (GTK)

From http://maemo.org/intro/: "Maemo is a software platform that is mostly based on open source code and powers mobile devices such as the Nokia N810 Internet Tablet. Maemo platform has been developed by Nokia in collaboration with many open source projects such as the Linux kernel, Debian, GNOME, and many more."

GTKTide by Mike Morrison is a fork of XTide 2.10 and libtcd with a GTK-based user interface, intended for use with Maemo. As of 2009-03-04, the last revision was in 2008-11 (source revision trunk-r7). GTKTide is available from http://maemo.org/downloads/product/OS2008/gtktide/.

GTKTide can be compiled and run under desktop Linux, though not necessarily with ease. Under Slackware 12.2, the build scripts did not configure dependencies correctly, and it took a long line of CPPFLAGS and LDFLAGS to make it go.

The GTK interface performs well for the common use case of viewing the tide graph for a specified location, but the controls needed to engage other modes of operation and to tweak XTide settings are absent.

Palm

Palm

Walt Bilofsky implemented Tide Tool for the Palm Pilot or any other compatible device running PalmOS. Bilofsky wrote: "Tide Tool used to qualify as a port, and still has a modest amount of code from XTide 1.5. But since Jeff Dairiki redid the algorithm to use integer math, I'm not sure how much of it is XTide any more. I guess I'd call it the descendant of a port."

Pocket PC / Windows CE

PocketPC

Dave Buchholz implemented cTide for the PocketPC 2000 or PocketPC 2002. It's a port of a port (WXTide32), but the screenshots still look a lot like XTide. You can find it at http://airtaxi.net/ctide/.

J2ME (cell phone)

Nokia phone with muTide

Jörn Eichler implemented an XTide-derivative called µTide for the J2ME platform. It is designed for modern smart phones like the Nokia N series, which have decent performance at floating-point math. It used to be at http://www.tj-eichler.de/muTide/; as of 2016-01 this URL has been redirected to advertising.

Timex Datalink USB

Timex Datalink with DTide

Paulo Marques implemented DTide for the Timex Datalink USB wristwatch. It uses a patched version of WXTide32 on the PC to allow the user to select locations and prepare simplified harmonics data to feed the application on the watch. It can store more than 200 (simplified) locations in the watch's memory. The application on the watch is an assembly language non-port using only integer math.

To get the application, download TreeBrowser_vX.zip and Tree Browser Feeders/DTide.zip from the Files > WristApps archive of Yahoo Group timexdatalinkusb.

To get the source (TreeBrowser asm and patch against WXTide32), download TreeBrowser_src.zip and DTide_src.zip from the Files > WristApps archive of Yahoo Group timexdatalinkusbdevelop.

HP Calculator

HP Calculator

David MacCuish and Dennis Straley did a similar-in-spirit non-port for HP48G and HP49G series calculators. As of 2011-08-28, the original HpTide site at http://heygus.2y.net/hptide is gone, but version 0.3.2 (2001-11-11) is archived at http://www.hpcalc.org/details.php?id=3943.


XTide Usage

 Winter Harbor, ME About this tide


Using the interactive interface

The first time you run xtide, you will get a license and disclaimer window. Read it, then click "Don't show this again" and dismiss it.

When XTide is finished indexing the harmonics files, you get a location chooser consisting of a map window and a location list window. If XTide was built with GPS support and your GPS is present and working, the map zooms in on your current location automatically. Otherwise, the map initially shows an entire hemisphere of the globe.

The location list enumerates every tide station that is plotted on the map. Buttons with labels such as "A-S" and "S-Z" appear on the location list window if the list is too long to display all at once; use these buttons to switch between the different pieces of the list.

(If you do not get outlines of coastlines, please refer to the installation section regarding World Vector Shoreline files.)

Location list window

You can change to a flat map projection that shows the entire world at once by clicking on Flat. You can make this your default location chooser if desired using the control panel described in the next section.

You can zoom in on an area by clicking on the map with the left mouse button; zooming out is accomplished with the button at the bottom of the map window. Your view can be shifted left, right, up, or down using the arrow keys on the keyboard. The location list updates to contain only those tide stations that are visible. You can cause the location list to include all available locations at once by clicking on List All. This will also bring up any locations whose coordinates are unknown.

Instead of zooming, you can narrow the list to a small area by clicking on that area with the right mouse button. A circle will be drawn on the map indicating the area selected:

Location chooser window with circle

When you are ready to choose a location, you can either click on it in the location list or zoom down to it on the map and click on the appropriate red or green dot with the middle mouse button. (Red dots indicate tide stations; green dots indicate currents.) A tide or current graph for the selected location will then pop up.

The Backward and Forward buttons allow you to move forward or backward in time by a small amount. Pull down the Options menu to gain access to the Set Time option, which allows arbitrarily large adjustments. The Options menu also provides these other options:

Option | Function
Save | Export the contents of the window to a PNG, SVG, or text file, as appropriate. (In raw and medium rare modes, you are given the opportunity to adjust the start and end times for the output.)
Set Mark | See next section.
Convert ft<->m | Convert units to the preferred system.
Set Aspect | See next section.
Set Step | See next section.
New Graph Window | Pop up a graph mode window for the location.
New Plain Mode Window | Pop up a plain mode window for the location.
New Raw Mode Window | Pop up a raw mode window for the location.
New Medium Rare Mode Window | Pop up a medium rare mode window for the location.
New Clock Window | Pop up a clock mode window for the location.
About This Station | Show station metadata.
About XTide | Show XTide version and GPL.
New Location Chooser | Pop up a new location chooser.
Control Panel | See next section.

Without getting into the complicated options, you can navigate from the location chooser to a graph window to other modes for the same location as you see fit. Use the Dismiss buttons to get rid of windows that you are through with.

Text window

In text windows, you can use the Forward and Backward buttons to scroll forward and backward in time, or you can use the mouse wheel. Text windows provide the same Options menu that is available on graph windows.

Clock window Clock window with buttons

By default, clock windows first appear with no buttons whatsoever, which is how you want them if you are going to leave them running on your desktop. However, you can make the buttons appear and disappear by clicking anywhere on the graph inside of the clock window.

The Options menu is again the same. Forward and Backward buttons are not provided for the obvious reason.


Modes and formats

Morning in OC

Modes

This page provides an overview of the kinds of things that XTide can do. How to do them will be explained in the next section.

Graph mode

San Francisco graph

Graph mode gives you a plot of the water level (or water velocity, in the case of currents) versus time. The times of high and low tide (or max flood and max ebb) are printed across the top. Sunrise and sunset are denoted with different background colors; moonrise, moonset, and moon phases are shown along the bottom. A + mark on the graph indicates the conditions at the time that the graph was generated.

For currents, the times of slack water are also shown along the bottom. If necessary, crowding of the bottom caption line can be relieved in several ways (see Advanced usage).

Default current graph

Clock mode

Clock mode

Clock mode is similar to graph mode, but the captions are different and the window is automatically updated once a minute to show the latest conditions. From top to bottom, the window shows the current time, the next high tide (or maximum flood), the predicted height or velocity for the current time (shown with a +), and the next low tide (or maximum ebb). Other events like slack water and moon phases do not appear.

Classic analog tide clock If a tide clock is iconified using an ancient window manager like twm, the icon will appear as a classic round tide clock that gives a vague idea of where you are in the tide cycle. Unfortunately, this feature is not accessible at all from newer windows environments that disregard the old icon protocol. Even some of the old window managers had trouble with it; they would crash, or the icon would fail to update.

Plain mode

Plain text listing of events, no foo-foo.

San Francisco, California
37.8067° N, 122.4650° W

2003-02-13  2:17 PM PST   Moonrise
2003-02-13  3:25 PM PST  -0.32 feet  Low Tide
2003-02-13  5:46 PM PST   Sunset
2003-02-13 10:49 PM PST   4.64 feet  High Tide
2003-02-14  3:05 AM PST   3.16 feet  Low Tide
2003-02-14  5:44 AM PST   Moonset
2003-02-14  7:01 AM PST   Sunrise
2003-02-14  9:02 AM PST   6.27 feet  High Tide

Calendar mode

Calendar mode arranges most of the information available in text mode into a commonly used tabular layout.

January 2007

Day | High | Low | High | Low | High | Phase | Sunrise | Sunset | Moonrise | Moonset
Mon 01 | 3:48 AM EST 0.17 m | 9:58 AM EST −0.14 m | 5:07 PM EST 0.43 m |  |  |  | 7:26 AM EST | 4:53 PM EST | 2:49 PM EST | 5:49 AM EST
Tue 02 |  | 12:25 AM EST −0.01 m | 4:46 AM EST 0.16 m | 10:52 AM EST −0.14 m | 6:00 PM EST 0.42 m |  | 7:26 AM EST | 4:54 PM EST | 3:48 PM EST | 6:54 AM EST
Wed 03 |  | 1:15 AM EST −0.01 m | 5:40 AM EST 0.17 m | 11:45 AM EST −0.14 m | 6:50 PM EST 0.41 m | Full Moon | 7:26 AM EST | 4:55 PM EST | 4:54 PM EST | 7:49 AM EST
Thu 04 |  | 2:00 AM EST −0.01 m | 6:32 AM EST 0.18 m | 12:37 PM EST −0.13 m | 7:37 PM EST 0.39 m |  | 7:26 AM EST | 4:56 PM EST | 6:03 PM EST | 8:34 AM EST
Fri 05 |  | 2:42 AM EST −0.00 m | 7:20 AM EST 0.19 m | 1:28 PM EST −0.12 m | 8:21 PM EST 0.37 m |  | 7:26 AM EST | 4:57 PM EST | 7:10 PM EST | 9:09 AM EST
Sat 06 |  | 3:20 AM EST −0.00 m | 8:08 AM EST 0.20 m | 2:16 PM EST −0.10 m | 9:02 PM EST 0.35 m |  | 7:26 AM EST | 4:58 PM EST | 8:15 PM EST | 9:37 AM EST
Sun 07 |  | 3:56 AM EST −0.00 m | 8:56 AM EST 0.21 m | 3:04 PM EST −0.08 m | 9:40 PM EST 0.32 m |  | 7:26 AM EST | 4:59 PM EST | 9:17 PM EST | 10:02 AM EST

"Alt" calendar mode arranges the information into a traditional weekly calendar layout.

Sun 07 | Mon 08 | Tue 09 | Wed 10 | Thu 11 | Fri 12 | Sat 13
Low Tide −0.00 m 3:56 AM EST Sunrise 7:26 AM EST High Tide 0.21 m 8:56 AM EST Moonset 10:02 AM EST Low Tide −0.08 m 3:04 PM EST Sunset 4:59 PM EST Moonrise 9:17 PM EST High Tide 0.32 m 9:40 PM EST | Low Tide −0.01 m 4:28 AM EST Sunrise 7:26 AM EST High Tide 0.22 m 9:46 AM EST Moonset 10:23 AM EST Low Tide −0.05 m 3:53 PM EST Sunset 5:00 PM EST High Tide 0.30 m 10:16 PM EST Moonrise 10:17 PM EST | Low Tide −0.02 m 4:58 AM EST Sunrise 7:26 AM EST High Tide 0.22 m 10:39 AM EST Moonset 10:43 AM EST Low Tide −0.01 m 4:46 PM EST Sunset 5:00 PM EST High Tide 0.27 m 10:51 PM EST Moonrise 11:16 PM EST | Low Tide −0.04 m 5:28 AM EST Sunrise 7:25 AM EST Moonset 11:03 AM EST High Tide 0.24 m 11:35 AM EST Sunset 5:01 PM EST Low Tide 0.03 m 5:49 PM EST High Tide 0.24 m 11:27 PM EST | Moonrise 12:14 AM EST Low Tide −0.06 m 6:00 AM EST Sunrise 7:25 AM EST Last Quarter 7:45 AM EST Moonset 11:23 AM EST High Tide 0.25 m 12:32 PM EST Sunset 5:02 PM EST Low Tide 0.05 m 7:01 PM EST | High Tide 0.21 m 12:07 AM EST Moonrise 1:15 AM EST Low Tide −0.08 m 6:35 AM EST Sunrise 7:25 AM EST Moonset 11:46 AM EST High Tide 0.28 m 1:29 PM EST Sunset 5:04 PM EST Low Tide 0.06 m 8:18 PM EST | High Tide 0.18 m 12:52 AM EST Moonrise 2:17 AM EST Low Tide −0.09 m 7:15 AM EST Sunrise 7:25 AM EST Moonset 12:14 PM EST High Tide 0.30 m 2:22 PM EST Sunset 5:05 PM EST Low Tide 0.06 m 9:30 PM EST

Calendar mode is not available from the interactive client.

Banner mode

Banner mode is a specialization of graph mode for output on old tractor feed dot matrix or line printers that use continuous reams of paper. Also useful as a workaround if your printing application does stupid things with color graphs. The graph is turned sideways and the aspect ratio is adjusted for Pica type. This mode is only available in the command line client.

San Francisco, San Francisco Bay, California
37.8067° N, 122.4650° W

********-*****-*******************·············································
********2*****1*****0*****1*****2·····3·····4·····5·····6·····7·····82012-02-20
-4****** ***** ***** ***** ***** ····· ····· ····· ····· ····· ·····4:00 AM PST
********f*****f*****f*****f*****f·····f·····f·····f·····f·····f·····f··········
********t*****t*****t*****t*****t*····t·····t·····t·····t·····t·····t··········
-5********************************·············································
****Moonrise***********************+··|·····|·····|·····|·····|·····|··········
-***5:53 AM PST**********************·|·····|·····|·····|·····|·····|··········
-6************************************|·····|·····|·····|·····|·····|··········
****************************************····|·····|·····|·····|·····|··········
******************************************  |     |     |     |     |
-7******************************************|     |     |     |     |
**********************************************    |     |     |     |
************************************************  |     |     |     |
-8************************************************|     |     |     |
****************************************************    |     |     |
******************************************************  |     |     |
-9***************************************************** |     |     |
*********************************************************     |     |
*********************************************************     |     |2012-02-20
-10*******************************************************    |    10:08 AM PST
**********************************************************    |     |
**********************************************************    |     |
-11******************************************************     |     |
********************************************************|     |     |
******************************************************  |     |     |
-12*************************************************    |     |     |
************************************************* |     |     |     |
**********************************************    |     |     |     |
-1***************************************** |     |     |     |     |
****************************************    |     |     |     |     |
************************************  |     |     |     |     |     |
-2*******************************     |     |     |     |     |     |
******************************  |     |     |     |     |     |     |
***************************     |     |     |     |     |     |     |
-3*********************** |     |     |     |     |     |     |     |
***********************   |     |     |     |     |     |     |     |

Stats mode

Stats mode is mainly for finding the highest high tide and lowest low tide within some period of time. However, it also provides an estimation of the Mean Lower Low Water datum based on the generated predictions. In cases where an authoritative benchmark for a station is not available, this can be used to derive a reasonable approximation. If the datum for the station has already been set to MLLW (as it should have been, for all U.S. stations) then the estimated value should be close to zero.

Stats mode is only available in the command line client.

Bar Harbor, Frenchman Bay, Maine
44.3917° N, 68.2050° W

Estimated upper bound:  14.05 feet
Estimated lower bound:  -2.71 feet
Mean, assuming symmetry:   5.67 feet

Searched interval from 2007-01-01 12:00 AM EST to 2008-01-01 12:00 AM EST
Maximum was  13.44 feet at 2007-11-25 10:31 AM EST
Minimum was  -2.05 feet at 2007-04-18  5:53 AM EDT
Mean of maxima and minima was   5.67 feet
Estimated MLLW:   0.15 feet

CPU time used:  0.280000 s

Raw mode

Raw mode is for getting machine-readable output that can be fed into other Unix programs. The first column is a Unix time_t timestamp (seconds since 1970-01-01 00:00Z); the second column is tide heights in whatever units were selected for the location.

896624777 0.180580
896628377 1.271889
896631977 3.463100
896635577 6.084148
896639177 8.402840
896642777 9.943272
896646377 10.421064
896649977 9.672793
896653577 7.856022
896657177 5.543402
896660777 3.413487
896664377 1.926805
896667977 1.371479

Medium rare mode

Medium rare mode is just like raw mode except that the timestamps are "cooked" according to the date and time format settings that are in effect.

2002-02-06  4:56 PM EST 2.054437
2002-02-06  5:56 PM EST 1.573781
2002-02-06  6:56 PM EST 1.086896
2002-02-06  7:56 PM EST 0.656111
2002-02-06  8:56 PM EST 0.224729
2002-02-06  9:56 PM EST -0.161049
2002-02-06 10:56 PM EST -0.265521
2002-02-06 11:56 PM EST 0.077530

List mode

List mode does not provide tide predictions at all. It is simply a way to get the list of supported locations from the command line client.

The 'Type' column shows Ref for reference stations and Sub for subordinate stations. You should care about the difference.

Location | Type | Coordinates
0.8 n.mi. above entrance, Alloway Creek, New Jersey | Sub | 39.4967° N, 75.5167° W
130th Street, Hudson River, New York | Sub | 40.8167° N, 73.9667° W
2.5 miles above mouth, Little Satilla River, Georgia | Sub | 31.0583° N, 81.4933° W
2.5 n.mi. above entrance, Alloway Creek, New Jersey | Sub | 39.5050° N, 75.4833° W
3 miles above A1A highway bridge, Loxahatchee River, Florida | Sub | 26.9700° N, 80.1267° W
37th Avenue, Long Island City, East River, New York, New York | Sub | 40.7617° N, 73.9467° W

About mode

About mode does not provide tide predictions either. Instead, it shows the metadata for a station ("About this station").

Name | Bar Harbor, Frenchman Bay, Maine
In file | /home/dave/svnrepo/software/xtide/harmonics-dwf-20111230-free.tcd
Station ID context | NOS
Station ID | 8413320
Date imported | 2011-12-25
Coordinates | 44.3917° N, 68.2050° W
Country | U.S.A.
Time zone | :America/New_York
Native units | feet
Source | http://tidesandcurrents.noaa.gov/
Restriction | Public domain
Comments Harmonic constants from web snapshot taken 2011-12-11
Datum from benchmark sheet, publication date 2011-09-29
Credit Processed by David Flater for XTide
https://flaterco.com/xtide/
Original name | Bar Harbor, ME
State | ME
Type | Reference station, tide
Meridian | 0:00
Datum | Mean Lower Low Water
Confidence | 10

Formats

XTide can render output in eight different formats: X-windows, HTML, LaTeX, iCalendar, PNG, CSV, SVG, or text. The X-windows format is implicit in the interactive client and can't be selected explicitly. The others can be selected in the non-interactive client and are invoked automatically by the interactive and web clients (e.g., when you save output to a file).

The currently supported combinations of mode and format are as follows:

Mode | Legal forms
about | text, HTML, X-windows
banner | text
calendar | text, HTML, LaTeX, iCalendar, CSV
alt. calendar | text, HTML, LaTeX
clock | text, PNG, SVG, X-windows
graph | text, PNG, SVG, X-windows
list | text, HTML
plain | text, X-windows, CSV
raw | text, X-windows, CSV
medium rare | text, X-windows, CSV
stats | text

The HTML and PNG formats are adequately demonstrated by the examples above in the Modes section.

Text format

Several of the preceding examples, like plain mode, were in text format. Here is an example of graph mode using the text format:

·················San Francisco, San Francisco Bay, California            ······
-12·····2003-02-13·············2003-02-13                 2003-02-13     ······
 PST····2:18 AM PST············8:12 AM PST                3:25 PM PST    ······
································                                         ······
································                                         ······
································                                         ······
································                                         ······
2 m·---------------------------------------------------------------------------
·····························*************                               ······
··························******************                             ······
***···················************************                           ······
**********·······*******************************                         ······
1 m***********************************************-----------------------------
****************************************************                     ·····*
******************************************************                   ···***
********************************************************                 ******
**********************************************************            *********
0 m****************************************************************************
*******************************************************************************
*******************************************************************************
********************Moonset****************************Moonrise****************
******************4:51 AM PST*************************2:17 PM PST**************
1**12***1***2***3**4***5***6***7***8***9*10**11**12***1***2***3***4**5***6***7*
|**|||**|***|***|**|***|***|***|***|***|**|***|***|***|***||**|***|**|***|***|*

Calendar mode is kind of cramped in text format if you use all default settings, but it can be made to work by using a compact time format, setting a wider TTY width, and/or turning off sun and moon information. These are settings that you can change with the control panel or command-line switches. See Appendix C for related discussion.

Bar Harbor, Frenchman Bay, Maine
44.3917° N, 68.2050° W

                                   May 2006

Day    High   Low    High   Low    High   Phase  Sunris Sunset Moonri Moonse
Mon 01 01:42  08:10  14:23  20:23                05:23  19:36  07:38
Tue 02 02:32  09:02  15:16  21:16                05:22  19:37  08:38  00:32
Wed 03 03:25  09:56  16:10  22:12                05:20  19:39  09:44  01:17
Thu 04 04:21  10:52  17:07  23:12                05:19  19:40  10:51  01:52
Fri 05 05:20  11:49  18:05                First  05:18  19:41  11:58  02:19
Sat 06        00:13  06:20  12:45  19:01         05:16  19:42  13:03  02:40
Sun 07        01:11  07:18  13:38  19:52         05:15  19:44  14:07  02:59
Mon 08        02:06  08:12  14:26  20:39         05:14  19:45  15:10  03:15
Tue 09        02:55  09:01  15:10  21:21         05:12  19:46  16:14  03:31
Wed 10        03:39  09:46  15:51  21:59         05:11  19:47  17:19  03:47
Thu 11        04:21  10:27  16:28  22:36         05:10  19:48  18:27  04:05
Fri 12        04:59  11:06  17:05  23:11         05:09  19:49  19:38  04:26
Sat 13        05:36  11:45  17:41  23:48  Full M 05:07  19:51  20:51  04:52
Sun 14        06:15  12:24  18:19                05:06  19:52  22:02  05:26
Mon 15 00:26  06:55  13:05  18:59                05:05  19:53  23:07  06:11
Tue 16 01:08  07:38  13:49  19:44                05:04  19:54         07:08
Wed 17 01:55  08:25  14:38  20:35                05:03  19:55  00:02  08:17
Thu 18 02:46  09:18  15:32  21:32                05:02  19:56  00:45  09:34
Fri 19 03:43  10:14  16:30  22:34                05:01  19:57  01:19  10:53
Sat 20 04:45  11:13  17:30  23:40         Last Q 05:00  19:58  01:46  12:12
Sun 21 05:50  12:14  18:31                       04:59  19:59  02:08  13:30
Mon 22        00:46  06:56  13:14  19:31         04:58  20:00  02:29  14:47
Tue 23        01:50  07:59  14:12  20:27         04:57  20:01  02:49  16:05
Wed 24        02:49  08:59  15:07  21:21         04:56  20:02  03:10  17:23
Thu 25        03:45  09:56  15:59  22:12         04:56  20:03  03:34  18:43
Fri 26        04:38  10:49  16:49  23:00         04:55  20:04  04:03  20:01
Sat 27        05:28  11:39  17:38  23:48  New Mo 04:54  20:05  04:40  21:15
Sun 28        06:16  12:27  18:25                04:53  20:06  05:26  22:18
Mon 29 00:34  07:03  13:15  19:13                04:53  20:07  06:23  23:09
Tue 30 01:21  07:51  14:03  20:01                04:52  20:08  07:27  23:49
Wed 31 02:09  08:38  14:51  20:50                04:52  20:09  08:35

SVG format

XTide can produce output in the Scalable Vector Graphics (SVG) format for graph and clock modes. Graphs in SVG format ought to look better in a web browser than graphs in PNG format, but unfortunately, fonts. Moreover, font metrics.

If your browser supports SVG, an SVG-formatted graph might appear here:

LaTeX format

Running LaTeX formatted output through pdflatex yields a PDF that looks approximately like this. See Appendix C for hints on obtaining the best results.

iCalendar format

The iCalendar format yields an .ics file that can be imported by standards-compliant calendar tools to put tide events on your schedule. It is only useful in calendar mode.

CSV format

CSV stands for Comma-Separated Values, a.k.a. comma-delimited. This rigid format is useful for importing XTide output into database and spreadsheet applications with fixed columns. Commas that are part of field values are replaced by the pipe character (|).

Washington| D.C.,2004-03-04,3:40 PM EST,,Moonrise
Washington| D.C.,2004-03-04,6:04 PM EST,,Sunset
Washington| D.C.,2004-03-04,6:23 PM EST,2.75 ft,High Tide
Washington| D.C.,2004-03-05,1:30 AM EST,0.21 ft,Low Tide

In calendar mode, the columns in CSV format are: location name, date, five reps of (max time, max value), five reps of (min time, min value), ten reps of slack time, sunrise, sunset, moonrise, moonset. The number of columns allocated is controlled by the compile-time constants numMaxMin and numRiseSet in CalendarFormC.cc. Events exceeding the number of columns available are discarded with a warning. Moon phases and mark level crossings are just discarded.

The use of compile-time constants instead of dynamically adjusted values is intentional, since whatever application is reading the CSV output needs the interpretation of columns to be predictable. However, the default configuration allowing one column for rise and set events is not always adequate. Yes! You can have two sunsets in one day, and you don't even need Daylight Savings Time to do it:

Isla Neny, Antarctica
68.2000° S, 67.0000° W

2001-01-24 12:03 AM ARST   Sunset
2001-01-24  3:17 AM ARST   Sunrise
2001-01-24 11:57 PM ARST   Sunset


Customizing XTide

XTide is customized by changing its settings. The most convenient way to do this is generally through the control panel that is documented in a previous section. However, you can also change these settings in config.hh, in your X resources database, or on the command line. The order of precedence, from least significant to most significant, is:

  1. config.hh
  2. Xdefaults (X resources)
  3. ~/.xtide.xml (control panel)
  4. command line

Note that only xtide (not xttpd or tide) reads Xdefaults.

Canonically, all command line settings take the form –xx value, with a space between the switch and the supplied value. The yes-or-no settings get a value of "y" or "n". However, XTide understands the following syntactic shortcuts:

  • Arguments can be concatenated with their switches.
  • A yes/no switch that omits its argument implies "y".
  • Using +xx instead of –xx for a yes/no switch inverts the argument (so if the argument is omitted, "n" is implied).

Some shorthand forms are ambiguous. For example, –lw5 could mean "set the line width to 5" (–lw 5) or it could mean "load the location named w5" (–l w5). If this happens, you will get an error and will need to spell out what you meant.

Be aware that older versions of XTide will not support all of the documented settings.

XTide*background
Background color for text windows and location chooser.
Default: white
Command line: –bg
config.hh: bgdefcolor
.xtide.xml: <xtideoptions bg="white"/>
XTide*buttoncolor
Background color of buttons.
Default: gray80
Command line: –bc
config.hh: buttondefcolor
.xtide.xml: <xtideoptions bc="gray80"/>
XTide*caldayfmt
(New in XTide 2.14) Strftime style format string for printing days in calendars.
Default: %a %d
Command line: –cf
config.hh: caldayfmt
.xtide.xml: <xtideoptions cf="%a %d"/>
XTide*cbuttons
Create tide clocks with buttons? (y/n)
Default: n
Command line: –cb
config.hh: cbuttons
.xtide.xml: <xtideoptions cb="n"/>
XTide*cheight
Initial height for tide clocks.
Default: 312
Command line: –ch
config.hh: defcheight
.xtide.xml: <xtideoptions ch="312"/>
XTide*currentdotcolor
Color of dots indicating current stations in the location chooser.
Default: rgb:00/A0/00
Command line: –cc
config.hh: currentdotdefcolor
.xtide.xml: <xtideoptions cc="rgb:00/A0/00"/>
XTide*cwidth
Initial width for tide clocks.
Default: 84
Command line: –cw
config.hh: defcwidth
.xtide.xml: <xtideoptions cw="84"/>
XTide*datefmt
Strftime style format string for printing dates. For calendars see caldayfmt.
Default: %Y-%m-%d
Command line: –df
config.hh: datefmt
.xtide.xml: <xtideoptions df="%Y-%m-%d"/>
XTide*datumcolor
Color of datum line in tide graphs. [*]
Default: white
Command line: –Dc
config.hh: datumdefcolor
.xtide.xml: <xtideoptions Dc="white"/>
XTide*daycolor
Daytime background color in tide graphs.
Default: SkyBlue
Command line: –dc
config.hh: daydefcolor
.xtide.xml: <xtideoptions dc="SkyBlue"/>
XTide*ebbcolor
Foreground in tide graphs during outgoing tide.
Default: SeaGreen
Command line: –ec
config.hh: ebbdefcolor
.xtide.xml: <xtideoptions ec="SeaGreen"/>
XTide*eventmask
Events to suppress (p = phase of moon, S = sunrise, s = sunset, M = moonrise, m = moonset), or x to suppress none. E.g, to suppress all sun and moon events, set eventmask to the value pSsMm.
Default: x
Command line: –em
config.hh: eventmask
.xtide.xml: <xtideoptions em="x"/>
XTide*extralines
Draw datum and middle-level lines in tide graphs? (y/n) [*]
Default: n
Command line: –el
config.hh: extralines
.xtide.xml: <xtideoptions el="n"/>
XTide*flatearth
Prefer flat map to round globe location chooser? (y/n)
Default: n
Command line: –fe
config.hh: flatearth
.xtide.xml: <xtideoptions fe="n"/>
XTide*floodcolor
Foreground in tide graphs during incoming tide.
Default: Blue
Command line: –fc
config.hh: flooddefcolor
.xtide.xml: <xtideoptions fc="Blue"/>
XTide*font
Font used for button labels and verbiage in text windows. [**]
Default: as incoming from X11 or libXaw3dXft
Command line: –fn
config.hh: N/A
.xtide.xml: N/A
XTide*foreground
Color of text and other notations.
Default: black
Command line: –fg
config.hh: fgdefcolor
.xtide.xml: <xtideoptions fg="black"/>
XTide*gaspect
Initial aspect for tide graphs and clocks.
Default: 1.0
Command line: –ga
config.hh: defgaspect
.xtide.xml: <xtideoptions ga="1.0"/>
XTide*gheight
Initial height for tide graphs.
Default: 312
Command line: –gh
config.hh: defgheight
.xtide.xml: <xtideoptions gh="312"/>
XTide*globelongitude
Initial center longitude for location chooser. If GPS support is present and working, this setting is redundant.
Valid values: –180 –150 –120 –90 –60 –30 0 30 60 90 120 150 360
360 will pick the longitude with the most tide stations.
Default: 360
Command line: –gl
config.hh: defgl
.xtide.xml: <xtideoptions gl="360"/>
XTide*graphfont
Font used in graphs and clocks in interactive client. Does not affect tide, xttpd, or SVG-format output. [**]
Default: "embedded"
Command line: –gf
config.hh: defgraphfont
.xtide.xml: <xtideoptions gf="embedded"/>
XTide*graphstyle
Style of graphs and clocks.
Valid values: d (default), l (line), s (semitransparent).
Default: d
Command line: –gs
config.hh: defgraphstyle
.xtide.xml: <xtideoptions gs="d"/>
XTide*graphtenths
Label tenths of units in tide graphs? (y/n)
Default: n
Command line: –gt
config.hh: graphtenths
.xtide.xml: <xtideoptions gt="n"/>
XTide*gwidth
Initial width for tide graphs.
Default: 960
Command line: –gw
config.hh: defgwidth
.xtide.xml: <xtideoptions gw="960"/>
XTide*hourfmt
Strftime style format string for printing hour labels on time axis.
Default: %l
Command line: –hf
config.hh: hourfmt
.xtide.xml: <xtideoptions hf="%l"/>
XTide*infer
Use inferred values for some constituents. For expert use only.
Default: n
Command line: –in
config.hh: infer
.xtide.xml: <xtideoptions in="n"/>
XTide*linebreak
(New in XTide 2.14) Linebreak before prediction value in calendars? (y/n)
Default: n
Command line: –lb
config.hh: linebreak
.xtide.xml: <xtideoptions lb="n"/>
XTide*lwidth
Width of line in graph styles l and s (pixels, positive real number).
Default: 2.5
Command line: –lw
config.hh: deflwidth
.xtide.xml: <xtideoptions lw="2.5"/>
XTide*markcolor
Color of mark line in graphs.
Default: red
Command line: –mc
config.hh: markdefcolor
.xtide.xml: <xtideoptions mc="red"/>
XTide*monofont
Monospace font used for location list, text predictions, help windows and about mode text. [**]
Default: "-misc-fixed-medium-r-normal--13-100-100-100-c-70-iso8859-1" (without libXaw3dXft) or "LiberationMono-12" (with libXaw3dXft)
Command line: –mf
config.hh: defmonofont
.xtide.xml: <xtideoptions mf="LiberationMono-12"/>
XTide*mslcolor
Color of middle-level line in tide graphs. [*]
Default: yellow
Command line: –Mc
config.hh: msldefcolor
.xtide.xml: <xtideoptions Mc="yellow"/>
XTide*nightcolor
Nighttime background color in tide graphs.
Default: DeepSkyBlue
Command line: –nc
config.hh: nightdefcolor
.xtide.xml: <xtideoptions nc="DeepSkyBlue"/>
XTide*nofill
Deprecated. Use graphstyle instead.
Default: n
Command line: –nf
config.hh: N/A (use graphstyle)
.xtide.xml: <xtideoptions nf="n"/>
XTide*nosunmoon
Deprecated. Use eventmask instead.
Default: n
Command line: –ns
config.hh: N/A (use eventmask)
.xtide.xml: <xtideoptions ns="n"/>
XTide*omitunits
(New in XTide 2.14) Print numbers with no ft/m/kt? (y/n) Where possible, adds a header line stating the units and datum.
Default: n
Command line: –ou
config.hh: omitunits
.xtide.xml: <xtideoptions ou="n"/>
XTide*pagebreak
(New in XTide 2.14) Pagebreak and header before every month of a calendar? (y/n)
Default: y
Command line: –pb
config.hh: pagebreak
.xtide.xml: <xtideoptions pb="y"/>
XTide*pageheight
Nominal length of paper in LaTeX output (mm). This need not match your actual paper; use "Shrink oversized pages" in print options.
Default: 420
Command line: –ph
config.hh: defpageheight
.xtide.xml: <xtideoptions ph="420"/>
XTide*pagemargin
Nominal width of top, bottom, left and right margins in LaTeX output (mm). Actual width will depend on print scaling.
Default: 10
Command line: –pm
config.hh: defpagemargin
.xtide.xml: <xtideoptions pm="10"/>
XTide*pagewidth
Nominal width of paper in LaTeX output (mm). This need not match your actual paper; use "Shrink oversized pages" in print options.
Default: 297
Command line: –pw
config.hh: defpagewidth
.xtide.xml: <xtideoptions pw="297"/>
XTide*predictinterval
Number of days of predictions to generate when no end time is specified.
Default: 4
Command line: –pi
config.hh: defpredictinterval
.xtide.xml: <xtideoptions pi="4"/>
XTide*tidedotcolor
Color of dots indicating tide stations in the location chooser.
Default: red
Command line: –tc
config.hh: tidedotdefcolor
.xtide.xml: <xtideoptions tc="red"/>
XTide*tideopacity
Opacity of the fill in graph style s (semitransparent).
Default: 0.65
Command line: –to
config.hh: deftideopacity
.xtide.xml: <xtideoptions to="0.65"/>
XTide*timefmt
Strftime style format string for printing times.
Default: %l:%M %p %Z
Command line: –tf
config.hh: timefmt
.xtide.xml: <xtideoptions tf="%l:%M %p %Z"/>
XTide*toplines
Draw depth lines on top of tide graph? (y/n)
Default: n
Command line: –tl
config.hh: toplines
.xtide.xml: <xtideoptions tl="n"/>
XTide*ttyheight
Height of ASCII graphs and clocks (characters).
Default: 24
Command line: –th
config.hh: defttyheight
.xtide.xml: <xtideoptions th="24"/>
XTide*ttywidth
Width of text format (characters).
Default: 79
Command line: –tw
config.hh: defttywidth
.xtide.xml: <xtideoptions tw="79"/>
XTide*units
Preferred units of length: ft, m, or x (no preference).
Default: x
Command line: –u
config.hh: prefunits
.xtide.xml: <xtideoptions u="x"/>
XTide*zulu
Coerce all time zones to UTC? (y/n)
Default: n
Command line: –z
config.hh: forceZuluTime
.xtide.xml: <xtideoptions z="n"/>

[*] The National Ocean Service (NOS) defines both Mean Sea Level (MSL) and Mean Tide Level (MTL) in terms of averages taken over observations. The middle-level line is drawn at the midpoint of the theoretical tidal range, which usually corresponds to the mathematical mean level of the predictions. This approximates both MSL and MTL, but, strictly speaking, is equivalent to neither. Moreover, subordinate station offsets may shift the actual mean so that it no longer falls at the midpoint of the tidal range. The datum line is drawn at the zero level of the predictions, which usually corresponds to the station's benchmark, but this too can be rendered inaccurate by subordinate station offsets.

[**] Important usage note: If XTide is built with Xaw3dXft, font names given to XTide must be in fontconfig format (e.g., "Helvetica-10"), rather than the traditional XLFD (e.g., "-*-helvetica-*-r-*-*-10-*-*-*-*-*-*-*"). Also, Xaw3dXft does not return errors if there are problems with a font name; it just loads a default font instead.

Format of ~/.xtide.xml

If you have compiled the interactive client (xtide), then you do not need to worry about ~/.xtide.xml at all, because the control panel will configure it for you automatically.

In the event that you cannot use xtide but still need to make some settings for the command line client, use the example below as the starting point for your ~/.xtide.xml file. This example just sets the TTY geometry. You can add more settings by adding more attributes (like the tw and th attributes shown here) to the xtideoptions entity. The attributes that are recognized for each setting are documented above.

<?xml version="1.0"?>
<xtideoptions tw="79" th="24"/>

Locale and terminal settings

Internally, XTide uses the Latin-1 (a.k.a. ISO-8859-1) character set exclusively. When generating output in text or HTML formats, XTide will convert Latin-1 characters to UTF-8 if that is what the POSIX locale asks for. This can be controlled with the LANG environment variable; e.g., LANG=en_US.UTF-8. Any other setting of the codeset portion of LANG (which has the format lang[_terr[.codeset]]) will result in Latin-1 characters being passed through unchanged. (CP437 is supported for DOS compatibility, but is rejected by Linux setlocale.)

If the environment variable TERM is set to vt100 or vt102, XTide will take it seriously and invoke the DEC Special Graphics character set in text format output. Below is a comparison of how graph mode, text format looks in an xterm normally (left) and with TERM set to vt100 (right). A VT100 provides five different horizontal line characters, which allow depth lines to be drawn more accurately. On the downside, it does not provide any of the accented characters from Latin-1, so non-ASCII characters in location names and other data received from the harmonics file will do something weird.


Advanced usage

Mark level

The "mark level" is a specific tidal height or current velocity of your choosing. When you set a mark level for a location, the times at which the tide level crosses the mark level will be displayed at the bottom of graphs and included in plain listings and calendars. This option is useful to determine the times when the tide will be low enough to expose something that is submerged at high tide or high enough to provide a desired depth. You can set a mark level by selecting the Set Mark option on the Options menu. In the following example, a mark level of 1 m has been applied to Bar Harbor predictions to find the approximate times at which one can walk to Bar Island without getting one's feet wet.

Bar Harbor with mark level

Mark level crossings are not displayed in clock mode windows due to lack of space.

Aspect

The "aspect" is a number that controls how stretched out or scrunched up a graph is. If timestamps are overlapping one another on a tide graph and becoming unreadable, you can increase the aspect to make them farther apart. An aspect of 1.0 is "normal;" an aspect of 2.0 stretches the graph by a factor of 2; an aspect of 0.5 does the opposite, compressing the graph. You can change the aspect by selecting the Set Aspect option on the Options menu.

Step

In raw and medium rare modes, tide levels are normally listed with an increment of one hour for successive lines of output. You can adjust this increment using the Set Step option.

The control panel

The control panel is the easiest way to customize the many user-serviceable settings of XTide. It is available from the options menu of prediction windows.

It's not pretty, but it gets the job done. The many individual settings have their many individual dialogs, and all are simply thrown together into a resizable window in no particular order. Resize and scroll as needed.

XTide control panel

Colors can be changed to any of the "standard" X-windows color names or to 24-bit RGB specifications of the form rgb:hh/hh/hh by typing the new colors in the dialog boxes. Fonts must be specified in fontconfig format (e.g., "Helvetica-10") if XTide was built with Xaw3dXft, or in traditional XLFD (e.g., "-*-helvetica-*-r-*-*-10-*-*-*-*-*-*-*") if not. Other settings have pull-down choice menus or counting buttons to help you along. Least user-friendly, but most powerful, are the timestamp formats. In return for reading the Unix man page for the strftime library function, you are empowered to change the timestamp formats to practically anything you could ever need.

You can choose Apply to see how the settings look in the current session only, or Save to make the settings permanent. They will be saved in the file ~/.xtide.xml. N.B., font changes require a restart to become effective.

Example 1: Alternate graph styles

Graphstyle l (line):

Graphstyle l example

Graphstyle s (semitransparent) with line width set to 1.5:

Graphstyle s example

Note that semitransparent style makes no sense in formats that don't support opacity (text and PseudoColor X-windows).

Example 2: Four ways to fix crowding of the bottom caption line

Original graph with crowded caption line:

Default current graph

With aspect 1.5 (to stretch out the graph):

Current graph with wider aspect

With time format "%H:%M" (to eliminate AM/PM and time zone verbiage):

Current graph with more concise time format

With event mask "Mm" (to filter out moonrise and moonset events):

Current graph with event mask

With graph font changed to LiberationSansNarrow-10:

Current graph with narrow font

Example 3: Two ways to fix missing depth axis

This station has such a small tidal range that the only label on the depth axis is zero meters, which is kind of useless:

Missing depth example

With option to label tenths of units enabled:

Missing depth example

With preferred units set to feet:

Missing depth example

Command line options

The interactive client supports all of the command line switches related to settings which are described in a later section. In addition, it supports the following.

–b "YYYY-MM-DD HH:MM"
With –l, specify the begin (start) time for predictions using the ISO 8601 compliant format YYYY-MM-DD HH:MM, where hours range from 00 to 23. The timestamp is in the local time zone for the location, or in UTC if the –z setting is engaged. If clock mode is selected or if no –b is supplied, the current time will be used. (Note Quirk #1)
–display "X display"
Specify the X display, e.g. "quake:0.0". This overrides the DISPLAY environment variable.
–geometry "±XOFF±YOFF"
Specify a position for the window corresponding to the first use of –l. (Width and height are controlled by different settings.)
–l "Location Name"
Specify a location for tide predictions. When given to the interactive client, this causes it to start a tide clock for the specified location instead of launching a location chooser on startup. This is useful for starting a tide clock automatically when you log on. Multiple uses of –l will result in multiple tide clocks.
–m a|g|k|m|p|r
With –l, specify mode to be about, graph, clock, medium rare, plain, or raw.
–ml [–]N.NN(ft|m|kt)
Specify an initial mark level to be used in prediction windows launched from the command line. The predictions will include the times when the tide level crosses the mark. The mark level also can be specified or changed using the Options menu. Not supported in clock mode. Does not affect windows that are launched from the location chooser. Example usage: –ml –0.25ft
–v
Print version string and exit. Please note that versions marked as DEVELOPMENT versions are not really versioned; they are work in progress and will change without warning.

If you use the same location a lot, you can set the environment variable XTIDE_DEFAULT_LOCATION to its name instead of using –l every time.

Other switches that are supported by the non-interactive interface are not supported by the interactive interface and will be ignored.

The arguments to –display, –fn, and –geometry cannot be concatenated with the switches (see Quirk #5).


Using the command line interface

The command line interface, tide, supports a number of modes that cannot be accessed with the interactive client. It can run without X-windows, and unlike the interactive client, it can easily be invoked from shell scripts.

The minimal usage is simply to specify a location with –l. The default mode is plain, and the default format is text:

$ tide -l "anchorage, al"
Anchorage, Alaska
61.2383° N, 149.8883° W

2003-02-12  7:27 AM AKST   Moonset
2003-02-12  8:50 AM AKST   Sunrise
2003-02-12 10:19 AM AKST  10.72 feet  Low Tide
2003-02-12 11:34 AM AKST   Moonrise
2003-02-12  3:42 PM AKST  24.41 feet  High Tide
2003-02-12  5:37 PM AKST   Sunset
2003-02-12 11:00 PM AKST   1.95 feet  Low Tide
2003-02-13  5:31 AM AKST  25.51 feet  High Tide
2003-02-13  8:29 AM AKST   Moonset

If you use the same location a lot, you can set the environment variable XTIDE_DEFAULT_LOCATION to its name instead of using –l every time.

The non-interactive client supports most of the command line switches related to settings which are described in a later section. (As a notable exception, the graph font cannot be changed.) In addition, it supports the following.

–b "YYYY-MM-DD HH:MM"
Specify the begin (start) time for predictions using the ISO 8601 compliant format YYYY-MM-DD HH:MM, where hours range from 00 to 23. The timestamp is in the local time zone for the location, or in UTC if the –z setting is engaged. If clock mode is selected or if no –b is supplied, the current time will be used. (Note Quirk #1)
–e "YYYY-MM-DD HH:MM"
Specify the end (stop) time for predictions in banner, calendar, alt. calendar, medium rare, plain, raw, or stats mode. Does not apply in graph and clock modes: the effective end time for graph and clock modes is entirely determined by the start time (–b), the width (–cw, –gw or –tw), and the aspect (–ga). The format and time zone are the same as for –b. If no –e is supplied, the end time will be set to four days after the begin time. (Note Quirk #2)

When it matters, –b and –e ranges mean specifically "all t such that b ≤ t < e."

–f c|h|i|l|p|t|v
Specify the output format as CSV, HTML, iCalendar, LaTeX, PNG, text, or SVG. See the modes page for legal modes and formats. The default is text.
–l "Location Name"
Specify a location for tide predictions. You get the first station where the name supplied with –l is a case-insensitive match with the beginning (or the entirety) of the station's name. You can use the –l switch more than once if you want to specify multiple locations.
–m a|b|c|C|g|k|l|m|p|r|s
Specify mode to be about, banner, calendar, alt. calendar, graph, clock, list, medium rare, plain, raw, or stats. See the modes page for legal modes and formats. The default is plain.
–ml [–]N.NN(ft|m|kt)
Specify the mark level to be used in predictions. The predictions will include the times when the tide level crosses the mark. Not supported in clock mode. Example usage: –ml –0.25ft
–o "filename"
Redirect output to the specified file (appends).
–s "HH:MM"
Specify the step interval, in hours and minutes, for raw or medium rare mode predictions. The default is one hour.
–v
Print version string and exit. Please note that versions marked as DEVELOPMENT versions are not really versioned; they are work in progress and will change without warning.

The interactive interface does not support all of these switches and options. Refer to the previous page for a list of the options supported by the interactive interface.

XTide understands the following syntactic shortcuts:

  • Arguments can be concatenated with their switches.
  • A yes/no switch that omits its argument implies "y".
  • Using +xx instead of –xx for a yes/no switch inverts the argument (so if the argument is omitted, "n" is implied).

Some shorthand forms are ambiguous. For example, –lw5 could mean "set the line width to 5" (–lw 5) or it could mean "load the location named w5" (–l w5). If this happens, you will get an error and will need to spell out what you meant.


Running the web server

xttpd is an XTide web server. It provides web-based access to XTide's tide predictions by allowing a web browser to speak directly to the XTide program in HTTP. xttpd can replace httpd or it can co-exist with one.

Once the port is established, xttpd will try to set its UID and GID to values that were specified at compile time. If it is unable to do this, it will log failure messages to syslog and then exit. Consequently, if it is to be started by someone other than root, that user's UID and GID must be configured at compile time. Instructions for doing this are available at https://flaterco.com/xtide/installation.html#xttpd.

You can set the address for feedback either at compile time as described in the installation instructions or with the environment variable XTTPD_FEEDBACK.

xttpd will accept settings either from command line switches (as used with xtide or tide) or from an .xtide.xml file that is saved in the home directory of the account that is used to execute it. Settings that are customized using the xtide control panel and then saved can be applied to xttpd by copying in the .xtide.xml file.

xttpd will produce a small number of zombie processes during normal operation. They are cleaned up after each new connection, so there is no cause for concern.

Since a web site is supposed to be self-explanatory, the process of using xttpd will not be documented here. If there are problems with people not being able to figure out how to use it, these should be reported to me as bugs, and the explanatory text in the web server will be updated accordingly.

Conventional operation

Usage: xttpd [port] [...other xtide settings switches...].

xttpd forks itself into the background and uses the syslog facility for all logging. Hosts connecting to xttpd are logged with priority INFO.

If you run xttpd with no command line arguments, it will assume that it is replacing httpd and try to bind port 80. If you want it to co-exist with an existing server, or if you do not have privilege to get port 80, give it the port number as the first command line argument:

% xttpd 8080

You will then need to link it up as http://www.wherever.org:8080/ instead of just http://www.wherever.org/, but otherwise, no damage done. Similarly, if you wish to bind a specific address, you can specify that as the first argument:

% xttpd 127.0.0.2

If you need to specify both address and port number, separate the two with a slash, like this:

% xttpd 127.0.0.2/8080

(New in XTide 2.15) IPv6 addresses and hostnames are now accepted for the address.

Systemd operation (XTide 2.15)

If xttpd was built with --enable-systemd, it cannot be run from the command line or from init scripts. The port, address, and command line options can only be changed by editing systemd config files as described in the installation section.

Command line switches for settings can be specified in xttpd.service on line ExecStart=.

Troubleshooting

Q: When I run xttpd, it exits immediately with no errors to tell me what went wrong.

A: When executed, xttpd immediately disassociates itself from your terminal and starts logging all diagnostics to syslog. So look in your system logs. On an init system, you will find these someplace like /var/log or /var/adm/log. On a systemd system, you have to say (as root) journalctl -b -p debug --no-pager to dump the log.

If all else fails, xttpd can be built with the debugging option -DXTTPD_NO_DAEMON to make it stay attached to the terminal and print errors to stderr. (Requires XTide 2.15)


Calculating Highest Astronomic Tides

As discussed on the Modes page under Stats Mode, the command line client; tide, is used in the determination of predicted minimum and maximum tides heights (among other modal data) which otherwise is not available from the GUI client, xtide. Before proceeding, it would be good for you to first review the list of commands at your disposal when using the terminal on the Using the Command Line Interface page; noting in particular, -ms (i.e., mode stats).

Example below of tide's statistical output for the 19-year search interval beginning in 2014.

Isle Au Haut, Penobscot Bay, Maine
44.0733° N, 68.6367° W

Estimated upper bound:  12.22 feet
Estimated lower bound:  -2.38 feet
Mean, assuming symmetry:   4.92 feet

Searched interval
from 2014-01-01 12:00 AM EST
to 2033-01-01 12:00 AM EST

Maximum was  11.93 feet at 2016-11-15 10:37
Minimum was  -2.02 feet at 2016-11-15  4:34
Mean of maxima and minima was   4.93 feet
Estimated MLLW:  -0.00 feet

NOAA Historic Photos

Photo above courtesy of the NOAA Photo Library showing a surveyor standing in the water mapping the coast using a plane table while another looks on. Location unknown.

Where, When and How

Where
The first argument of -l (location, and yes, that's a lower case L) needs to be entered between quotes, it is case-insensitive, and it will match the beginning of a string. If it could match more than one, you'll get the first one. The safest thing is to specify the complete name. For example, entering only "sandy point" would return:

1st Sandy Pt returned

If you're location is .5 mile south of Sandy Point on the Patuxent River, then you're all set as it's the first one of nine Sandy Points on the list.

which sandy point

terminal icon To see the entire list of nearly 4200 stations, type:

tide -ml

In the terminal, it (mode list) would appear like this:

top of the list of 4166 stations

There may be other situations where the station names that have been provided to you, say for example from the CO-OPS GIS Data Portal, are some variation of the name in the NOAA data listing used by tide. In such cases when tide does not find the station name or finds the incorrect station, using the Station's 7-digit ID will be necessary and will be discussed in detail under the section Working With Scripts.

When
The interval of the search needs to next be stated; otherwise, if left blank, tide will return predictions for the default 4-day interval from the system time of the query.

default search interval

Begin and end dates must be given in the following format and between quotes; "YYYY-MM-DD HH:MM" else XTide will issue a fatal error BAD_TIMESTAMP

Alaskan tide gauge
Image ID: theb2383 NOAA's Historic Coast & Geodetic Survey (C&GS) Collection
Location: Port Protection, Prince of Wales Island, Alaska
Photo Date: 1915
Credit: C&GS Season's Report Colbert 1915-18

The National Tidal Datum Epoch

The National Tidal Datum Epoch (NTDE) is a 19 year period. The period of analysis for a NTDE begins at 00:00 1 January of the 1st year of the analysis period and ends at 23:59 31 December of the final year.

The present NTDE is 1983 through 2001 and is actively considered for revision every 20-25 years.​

The current plan ​is to aim for ​20​02-​20​20 as the Epoch period​,​ and that the project would start for actually updating datums around 2022-2023​. This plan is subject to change depending on resources.

Further Reading
​There are several publications which discuss tidal datums and NTDE, below are just three. Several other resources are listed in XTide's Bibliography.

NOAA Tide and Current Glossary

NOAA Special Publication NOS CO-OPS 1 - Tide Datums and Their Applications

NOAA Special Publication NOS CO-OPS 2 - Computational Techniques for Tidal Datums Handbook

Note that details associated with how XTide handles historical predictions are fully presented in Appendix A and further addressed in this FAQ.

How
Even though tide's only legal output format for statistical information is text, you can begin to control how tide outputs the statistical information. Redirect the output from the terminal to a text file; i.e., by typing after -ms:

> stats.txt

To redirect and append multiple statistical results to that same text file, type after -ms:

>> stats.txt

In the terminal, it would look like this:

redirect and append

Add a divider
To improve the readability in the text file and separate multiple statistical results in that same text file, type after -ms:

>> ./Stats.txt; printf "\n\n+++++++++++++++\n\n" >> ./Stats.txt

In the terminal, it would look like this:

adding a divider

In the Stats.txt text file, it would look like this:

Umbrella Point, Trinity Bay, Texas
   29.6800° N, 94.8683° W
Estimated upper bound:   2.46 feet
   Estimated lower bound:  -1.07 feet
   Mean, assuming symmetry:   0.69 feet
Searched interval from 2016-12-01 12:00 AM CST to 2017-01-01 12:00 AM CST
   Maximum was   1.14 feet at 2016-12-01 12:27 AM CST
   Minimum was  -0.69 feet at 2016-12-30  2:43 PM CST
   Mean of maxima and minima was   0.33 feet
   Estimated MLLW:  -0.33 feet
CPU time used:  0.028000 s

+++++++++++++++
Alcatraz Island, San Francisco Bay, California
   37.8267° N, 122.4170° W
Estimated upper bound:   8.40 feet
   Estimated lower bound:  -2.16 feet
   Mean, assuming symmetry:   3.12 feet
Searched interval from 2016-12-01 12:00 AM PST to 2017-01-01 12:00 AM PST
   Maximum was   7.09 feet at 2016-12-13 10:24 AM PST
   Minimum was  -1.59 feet at 2016-12-14  5:58 PM PST
   Mean of maxima and minima was   3.22 feet
   Estimated MLLW:  -0.13 feet
CPU time used:  0.028000 s

+++++++++++++++
Bellingham Channel, off Cypress I. Light, Rosario Strait, Washington Current
   48.5603° N, 122.6637° W
   Flood direction 45° true
   Ebb direction 185° true
Estimated upper bound:   3.60 knots
   Estimated lower bound:  -4.89 knots
   Mean, assuming symmetry:  -0.64 knots
Searched interval from 2016-12-01 12:00 AM PST to 2017-01-01 12:00 AM PST
   Maximum was   2.96 knots at 2016-12-16  4:14 AM PST
   Minimum was  -4.28 knots at 2016-12-14  8:04 PM PST
   Mean of maxima and minima was  -0.49 knots
CPU time used:  0.024000 s

+++++++++++++++

Working with scripts

As previously mentioned, there may be situations where the entered station name is some variation of the name in the NOAA data listing used by tide. In such cases when tide does not find the station name or finds the incorrect station, using the Station's 7-digit ID will be necessary. This is when the use of a script can help, along with its accompanying list of stations with their ID numbers.

Below is the screen capture of an example shell script as displayed with syntax highlighting in the text editor Geany. The copiable text for the script is further below after the section on How to Create an XTide Station ID List. - see hatmode.sh

In the script, there are obvious bits of the script that you'll need to change; notably, at line number 22, the output directory. The other options identified by their respective comments (in red) can be turned on or off to suit your preferences using the comment symbol #

screen capture of script as displayed in Geany

For any given line, note that anything after the # is ignored by tide.

Note that when using the station list: sids.txt, if you search by station name, that it's case-sensitive. Also note that this list of tide stations prefaced by their identification numbers is date stamped and relates specifically with its corresponding harmonics file of even date. See the section below on How to Create an XTide Station ID List.

Make a copy of the hatmode.sh before editing it for safekeeping. Place the edited hatmode.sh and sids.txt files in the same folder. Before running the shell script, in Files (Nautilus) right click on the script, Properties, Permissions tab, and check the box to Allow executing file as program:

set permissions for shell script

terminal icon To obtain the highest astronomic tide for the tide station with an identification number of 8418150 for a 19-year interval beginning in 2014, run the shell script from the command line by typing:

./hatmode.sh "8418150" 2014

In the terminal, it would appear like this:

running the shell script single station

Note that results are written to the output folder identified in the shell script and that the name of the html document is automatically correspondingly named; in this example, ~/XTide/HAT/Results/8418150-hat19.html. In Firefox, the results would appear like this:

results displayed in Firefox

Bulk processing
If you have a list of stations to be processed, using a text editor create a new shell script that will call the hatmode.sh script for each station and the begin year; in this example I've used a begin year of 2014. To provide sufficient time for each station to be processed before tide begins its next calculation, I've added a 1-second sleep interval. This necessary pause may vary depending on your system and if needed, increase the sleep interval accordingly.

Other than the slight pause, the format for each line is pretty much the same as if manually entered from the terminal command line; i.e., call the script, location and begin year:

Because my list was of all the tide stations in Maine and the interval searched was 19 years, I named my script METS19.sh. Save your new script file with the .sh extension and place it with the edited hatmode.sh and sids.txt files in the same folder. Before running the shell script, in Files (Nautilus) right click on the script, Properties, Permissions tab, and check the box to Allow executing file as program:

Bulk HAT mode permissions

terminal icon Run the script from the command line by typing:

./METS19.sh

In the terminal, it would appear like this:

How to Create an XTide Station ID List

XTide's harmonics file is updated once a year thanks to the steadfast efforts of David Flater (https://www.flaterco.com/xtide/files.html#harmonicsfiles). This assures that as NOAA adds new tide stations and retires old ones, XTide's predictions include the same dataset used by NOAA.

The most recent list of station names and locations are date stamped the same as the harmonics file and can be found on the locations page: https://www.flaterco.com/xtide/locations.html

Method 1

In the hatmode.sh script above, the date stamped 20151227 list has been 1) saved as an html document; 2) then edited in a text editor; and 3) saved as a text file (.txt). In the text file, the header and footer should be removed. The station type and location fields should be deleted and the station ID and name kept on each line.

It will be most helpful if your text editor allows collumnar selections and the use of regular expressions. Below is an example using the date stamped 20161231 locations file.

editing an html into a txt

Method 2

Another way to create a station ID list uses the harmonics SQL database; e.g., https://flaterco.com/files/xtide/harmonics-dwf-20181227-SQL.tar.bz2 and the database program PostgreSQL

terminal icon From the ~/XTide folder, download and extract the SQL file by typing:

wget https://flaterco.com/files/xtide/harmonics-dwf-20181227-SQL.tar.bz2; tar xvf harmonics-dwf-20181227-SQL.tar.bz2

download and extract SQL file

If you don't have PostgreSQL on your system, go ahead and install it (and some other packages) from the terminal window with the following single line:

terminal icon From any folder, download and install PostgreSQL by typing this line in its entirety:

sudo apt install postgresql libpq-dev postgresql-client postgresql-client-common -y

First, run postgres, and then next create a postgres database user (use your own name!), answering the questions interactively as shown:

terminal icon From any folder, download and install PostgreSQL by typing this line in its entirety:

sudo su postgres

createuser kelly -P --interactive

my_secret_password

no

yes

yes

sudo su postgres

To exit out of postgres user and shell, type Ctrl+D twice, to return back to the normal user's prompt.

Change directory to the location of the harmonics-dwf-yyyymmdd.sql before creating the new database. Then begin with Super User switching to user postgres, create the new (empty) database named: harmbase2. Next import the data from the harmonics-dwf-yyyymmdd.sql file, connect to the harmbase2 database, and copy the fields STATION_ID and NAME to a new text file named sids.txt in a temporary location. Lastly, and as Super User, move the sids.txt file to the relevant directory. The entire process will look like this in the terminal:

terminal icon From the harmonics folder, create the station ID list by sequentially typing the following commands - pay attention to the screen capture of the terminal session below:

sudo su postgres

createdb harmbase2

psql harmbase2 < harmonics-dwf-20181227.sql

psql harmbase2

COPY DATA_SETS (STATION_ID, NAME) TO '/tm/sids.txt';

Ctrl+D

Ctrl+D

sudo mv /tmp/sids.txt ~/XTide/harmonics-dwf-20181227/sids.txt

psql to sids

hatmode.sh

#!/bin/bash
# HAT Mode Script
# This script is for running D.W. Flater's tide application to determine
         # the highest astronomic tide at a given tide station used in conjunction
         # with a list of tide stations contained in a separate file; sids.txt,
         # which include the station identification numbers. It is useful for when
         # station names used by XTide return unexpected or null results.
# Written by David W. Flater - thanks Dave :)
         # Last tweaked: 2016/12/13 11:41 (VKB)
         # Put full path in tideapp if needed
         tideapp=tide
# Output option 1
         # Output into the current directory
         # OUTDIR=.
# Output option 2
         # Output into an existing directory if not current
         OUTDIR=/home/kelly/XTide/HAT/Results

# A reminder to the user of the script that "location" and begin year
         # YYYY must be provided if those arguments aren't included after
         # entering ./hatmode.sh
         if [ -z "$1" -o -z "$2" ]; then
         echo Usage: hatmode station-id 2014
         exit
         fi
# Look up station name
         sname=`fgrep "${1}" sids.txt | head -1 | cut -f 2`
         if [ -z "${sname}" ]; then
         echo Station ID ${1} not found in sids.txt
         exit
         fi
ybegin="$2"
# Interval declaration
         # For highest annual tide, use +1
         # For highest astronomic tide during a Metonic cycle, use +19
         declare -i yend=${ybegin}+19
# Language Option 1
         # Specify Latin-1 (default expected by browsers) not UTF8
         # export LANG=en_US.ISO-8859-1
# Language Option 2 (elimianted Unbuntu's GTK-warning)
         export LANG=C
# Print button option created at top of html document
         echo "<FORM><INPUT TYPE="button" value=\"Print\" \
         onClick=\"window.print()\"></FORM><p>" > ${OUTDIR}/"${1}-"hat19.html
# Metadata option appends station details to the resulting html document
         ${tideapp} -l "${sname}" -ma -fh >> ${OUTDIR}/"${1}-"hat19.html
         echo "</p><p><pre>" >> ${OUTDIR}/"${1}-"hat19.html
# HAT data appended to the resulting html document
         ${tideapp} -l "${sname}" -b "${ybegin}-01-01 00:00" \
         -e "${yend}-01-01 00:00" -ms >> ${OUTDIR}/"${1}-"hat19.html
         echo "</pre></p>" >> ${OUTDIR}/"${1}-"hat19.html
# Optional call for browser to open resulting html document
         # firefox ${OUTDIR}/"${1}-"hat19.html &


Notes and Appendices

 Winter Harbor, ME About this tide


Frequently Asked Questions

Note: "Mumble Foo Bar" is a made-up place that is meant to represent whatever place you are looking for. Whatever is said in this FAQ about Mumble Foo Bar applies to your location as well.

Ultra-high frequency questions

  • Your tide predictor web site blah blah blah...
  • Can you send me predictions for Mumble Foo Bar?
  • URGENT - DROP EVERYTHING AND READ THIS! The race starts in 5 hours so I need a tide chart for Mumble Foo Bar NOW!
  • The ads on your web site are driving me nuts! Is there any way to turn them off?
  • Can you tell me where I can find a web page with predictions for Mumble Foo Bar?
  • Can you please add predictions for Mumble Foo Bar?
  • How do I make the calendar print all on one page?
  • Can you tell me the offsets for Mumble Foo Bar?
  • There are multiple listings for the same place, and they give different results. What's going on?
  • Can you predict the tide and/or current if I give you the latitude and longitude?
  • The coordinates you provide for Mumble Foo Bar are off by miles, or you misspelled Mumble Foo Bar.
  • Why are there few currents in the latest database?

XTide operational questions

  • I want to change the graph in lots of ways, e.g., omit the location name, draw different depth lines, bunch of other stuff; how can I do this or will you add settings for it?
  • Can I still install XTide if I do not have root?
  • I am trying to compile XTide with an unknown version of GCC, and I had the following problems....
  • I am trying to install XTide on a server that my web hosting company, contractor, or employee has configured in a nonstandard way and/or not updated in years. Their support is unhelpful. Please help me to get XTide to work on this server.
  • When compiling XTide with a modern version of GCC on a well-maintained computer, I get errors like....
  • What is the significance of the estimated bounds printed by stats mode?
  • Are these predictions compliant with the new Daylight Savings Time rules for ...?
  • I am doing some historical research and need to project what the tides would have been a long long time ago.
  • I live outside of the U.S. and my location is no longer supported. What happened?
  • I want to change the end time of a tide graph but the settings that I make have no effect.
  • The text in XTide windows uses uglyfont.
  • I applied a changed setting in the control panel, but it had no effect.
  • When I run xttpd, it exits immediately with no errors to tell me what went wrong.
  • I always get a warning about "using obsolete time zone database."
  • How do I switch from tide to current predictions or vice-versa for a given location?
  • What are bogo-knots?
  • First it says high tide is at 3:15 PM but then when I run it again it says 3:14 PM.
  • Has this been ported to Windows / PalmOS / anything but Unix?
  • Xttpd sucks! Can't XTide work with PHP?
  • The tides for my location are totally wrong!
  • The tides for Mumble Foo Bar are obviously bogus because they have too many high tides on this day / only one high tide on this day / tides that are just a few minutes apart.
  • I have five constituents and some seasonal corrections for my location. Can you get this to work?

General tide related questions

  • I have a tide watch that only goes through the year 1999. What year could I set it to that would be the same as this year?
  • Is there a set time advancement each day for the next high and low tide? Does it always repeat 12½ hours later?
  • Somebody gave me a tide clock, but the instructions say it only works on the east coast. How can this be?
  • Why do the high and low tides have such different levels to them on any given day?
  • If it's high tide here, is it low tide in [faraway place]?
  • What does the zero (0) on a tide chart represent?
  • Why is it that the tides two miles from here are an hour different than the tides here?
  • Why are there two high tides per day, anyway? How is this possible?
  • What does "slack water" mean?
  • I have a theory that [random phenomenon] is related to tidal forces, but I am landlocked. Can you, like, predict the "tides" for [landlocked location]?
  • I want to write my own tide predicting program. Can you provide a SIMPLE explanation of the tide-predicting function?

Business questions

  • I want to license XTide so I can build a commercial product around it.
  • I have a lot of specific questions about the GNU General Public License and/or want a ruling that my specific plan is OK.
  • I would like to talk to you concerning the use of your stuff in our upcoming product. Please call me at your convenience. [#include email legal disclaimer]
  • I really don't understand the whole purpose of the GNU license. Why should I have to reinvent the wheel just because I won't publish my sources?
  • We are a non-profit and we want to sell calendars with predictions from your web site. Is that OK?
  • I have a great idea to make money selling tide predictions, but I'm not good with technical stuff, so would you just do this for me...
  • I already make money selling tide prediction products, but your stuff is better, so would you just do this for me...
  • I just put up a fabulous website that serves up XTide output surrounded by banner ads that make me tons of free money. Would you please link to it?
  • Hey, that previous guy had a great idea. Would you please install XTide on my web server for me?
  • I'm a consultant being paid to install XTide. I'm having a million problems with it, but I can't describe them accurately because I have never used Linux before. I think XTide must be really broken. Please fix all of my problems.
  • I need to do [poorly researched brainstorm having something to do with tide prediction]—how much would you charge in consulting fees to help me do it?
  • Congratulations! XTide has been added to some online directory of software packages. Please verify that the information on XTide is correct and keep it updated.

Academic questions

  • How should I cite XTide within publications?

Questions that you should have asked, but didn't

  • What is the difference between a reference station and a subordinate station?
  • These predictions are nonsense—what is going on here?
  • Where can I find tons of information about tides that is both more authoritative and better written than this FAQ?

Ultra-high frequency questions

Q: Your tide predictor web site blah blah blah...

A: I am not the maintainer of the web site you have found. I am the maintainer of XTide. Although many tide-predicting web sites use some version of XTide behind the scenes, I have no control over the behavior of those web sites or their maintenance, nor do I receive any commissions from any advertising that may appear on them. The XTide software and required data are available free of charge from flaterco.com/xtide/files.html, with documentation at flaterco.com/xtide.

Q: Can you send me predictions for Mumble Foo Bar?

A: I cannot possibly provide this level of service to everyone who wants it. Please use a commercial service and/or a web site.

Q: URGENT - DROP EVERYTHING AND READ THIS! The race starts in 5 hours so I need a tide chart for Mumble Foo Bar NOW!

A: You might not believe it, but sometimes I go two weeks without reading my e-mail. Really! And when I do get back to it, there are always lots of messages just like this one, so far past their use-by dates that green fuzz has started to grow on them. The answer is the same: I cannot possibly provide this level of service to everyone who wants it. Please use a commercial service and/or a web site.

Q: The ads on your web site are driving me nuts! Is there any way to turn them off?

A: I am not the maintainer of the web site with which you are having a problem. I am the maintainer of the XTide software that you can get free with no ads from flaterco.com/xtide. Others have profited by selling advertisements on other web sites built using my software, but I give away the software freely to anyone who will make the effort to install it, so nobody really needs to be using those web sites.

Q: Can you tell me where I can find a web page with predictions for Mumble Foo Bar?

A:

  • Canada: Fisheries and Oceans Canada
  • Germany: Bundesamt für Seeschifffahrt und Hydrographie (BSH)
  • Netherlands: Ministerie van Verkeer en Waterstaat—oops, there's been a reorg
  • New Zealand: Land Information New Zealand (LINZ)
  • Norway: Norwegian Hydrographic Service
  • U.K.: National Tidal and Sea Level Facility (NTSLF)
  • U.K.: U.K. Hydrographic Office
  • U.S.A.: National Ocean Service (NOS), Center for Operational Products and Services (CO-OPS)

Q: Can you please add predictions for Mumble Foo Bar?

A: Probably not. Please read the section entitled What to do if your location isn't listed.

Q: How do I make the calendar print all on one page?

A: The short answer for Windows users is to do the following:

  1. Bring the calendar up in Internet Explorer.
  2. Read this: How to use Print Preview
  3. Pull down the print size menu ( Shrink To Fit) and try different options until the calendar fits nicely on a page.
  4. When ready, click on the tiny printer icon to print.

For a more complete answer and/or instructions tailored for Linux, see Appendix C.

Q: Can you tell me the offsets for Mumble Foo Bar?

A: You can get them easier than I can by checking the sources described in the section entitled What to do if your location isn't listed.

Q: There are multiple listings for the same place, and they give different results. What's going on?

A: There are two different approaches to predicting the tides at a given place. One approach is to calculate them directly from a data set; when this is done it is called a "reference station." The other approach is to estimate them using adjustments to the tides at a nearby reference station; when this is done it is called a "subordinate station."

Data gathered from the NOAA web site sometimes include both a reference station and a subordinate station for the same place. For example, the subordinate station may be used for published tide tables while the reference station is still relatively new and untested. The results will differ, but they should be close (assuming that there are no problems with the data). If you are concerned about matching predictions up with those from some particular source, you should try each data set and see which one matches the best.

In rare cases, data gathered from the NOAA web site include two reference stations or two subordinate stations with exactly the same name and nearly the same location. When this happens, one of them has (2) suffixed to its name. Again, if you are trying to match official predictions, you should try both to determine which is better.

If you are using old legacy data or a web site that does, you may see additional listings for the same place. These may be expired and/or have dubious traceability to authoritative sources. They cannot be expected to agree with up-to-date predictions.

Q: Can you predict the tide and/or current if I give you the latitude and longitude?

A: The short answer is no. XTide cannot predict tides unless you provide harmonic constants (see What to do if your location isn't listed).

From what I'm told, the tide models that were built from TOPEX/Poseidon data work on a global scale, but they are inaccurate on continental shelves. Some organizations have constructed models that function in coastal waters in localized regions. For example, NIWA has a model for New Zealand's coastal waters, and NOAA has a model of currents in San Francisco Bay. Although XTide could make use of harmonic constants generated from these models, XTide does not implement any such models.

Q: The coordinates you provide for Mumble Foo Bar are off by miles, or you misspelled Mumble Foo Bar.

A: XTide reports coordinates in degrees only. Some sources report coordinates in degrees and minutes and run these together in a confusing way. For example, a coordinate shown as 2846.330 may actually mean 28 degrees, 46.330 minutes, which XTide would report as 28.7722 degrees.

If that is not sufficient to explain the discrepancy, or if there is some other cosmetic problem like the location name being spelled wrong, check NOAA's web site to see if the problem exists there. If it does, please report the problem to NOAA as well as me, and I will attempt to ensure that the correction is included in the next annual update.

Q: Why are there few currents in the latest database?

A: The Center for Operational Oceanographic Products and Services (CO-OPS) of NOAA's National Ocean Service (NOS) does not presently supply harmonic constants for currents on its public web site. This text from http://tidesandcurrents.noaa.gov/ncop.html may partially explain why not:

Approximately 70 percent of the stations in the 2001 Tidal Current Tables are over 30 years old. Many of these stations are based on analyses of less than 7 days of data (the data duration is known for 24% of all stations). Channel dredging and changes in the configuration of ports and harbors over the years have significantly altered the physical oceanography of many of the nation's estuaries. Reports from local users indicate that many of NOS's tidal current predictions may be inaccurate. NOS intends to address these deficiencies by rebuilding the program and resampling the currents at every major port and estuary within the next 20 years.

XTide operational questions

Q: I want to change the graph in lots of ways, e.g., omit the station name, draw different depth lines, add more event types; how can I do this or will you add settings for it?

A: XTide supports a fair number of options to customize the graph. However, graphing is not the core function of XTide. If complete control over graphing is important to you, you should use XTide's raw and plain modes to export the raw level data and min/max predictions respectively to text files, import these into R, Gnuplot, or whatever is the "flavor of the month" for graphing and plotting, and then draw what you like using these more powerful tools.

Q: Can I still install XTide if I do not have root?

A: Yes. Follow the installation instructions, and just use paths in your home directory instead of system-wide directories. Following is one example of how it would work if you have installed dependencies (libraries) under /home/myacct/local and wish to install xtide in the same directory tree.

bash-3.1$ # install harmonics file
bash-3.1$ bzip2 -d harmonics-dwf-YYYYMMDD-free.tcd.bz2
bash-3.1$ mkdir /home/myacct/local/share/xtide
bash-3.1$ mv harmonics-dwf-YYYYMMDD-free.tcd /home/myacct/local/share/xtide
bash-3.1$ # The following should go in ~/.bash_profile to make it permanent
bash-3.1$ export HFILE_PATH=/home/myacct/local/share/xtide
bash-3.1$ # compile and install XTide
bash-3.1$ ./configure --prefix=/home/myacct/local CPPFLAGS="-I/home/myacct/local/include" LDFLAGS="-L/home/myacct/local/lib -Wl,-rpath,/home/myacct/local/lib"
bash-3.1$ make
bash-3.1$ make install

In the unlikely event that you wish to run the web interface xttpd, you will need to run it on an unprivileged port as described in Running the web server.

Q: I am trying to compile XTide with an unknown version of GCC, and I had the following problems....

A: XTide requires GCC version 4.4 or newer. Type gcc -v to find out what version you have.

Q: I am trying to install XTide on a server that my web hosting company, contractor, or employee has configured in a nonstandard way and/or not updated in years. Their support is unhelpful. Please help me to get XTide to work on this server.

A: Sorry, but no. This is a problem with the service that your web hosting company, contractor, or employee is providing; it is not an XTide problem. In my experience, working around problems on a mismanaged or merely unmaintained server is an unending game of Whac-A-Mole. Your time would be better spent searching for a more competent web hosting company, contractor, or employee.

Q: When compiling XTide with a modern version of GCC on a well-maintained computer, I get errors like....

A: Please refer to the troubleshooting section of the installation instructions. If your error is not discussed there, please email dave@flaterco.com for assistance.

Q: What is the significance of the estimated bounds printed by stats mode?

A: The stats mode of XTide prints estimated upper and lower bounds that are calculated based on the 6 most significant tidal constituents simultaneously taking on their maximum and minimum possible values in the prediction model. These are not true bounds in the mathematical sense, since any station having more than 6 constituents could potentially generate predictions that exceed them. However, in practice, these estimated bounds are seldom exceeded by generated predictions.

Stats mode also determines and outputs the maximum and minimum predicted by the model within the span of time specified by the user. This generally provides a narrower interval, and one that is equally valid for the span of time specified. However, these bounds will vary depending on the span of time searched, while the estimated bounds are nearly constant.

Actual observed heights may exceed any and all bounds of the prediction model (e.g., in case of tidal surge from a hurricane). The highest and lowest water levels actually observed and recorded at a reference station during the official tidal epoch (presently 1983–2001) can be found in the Benchmark Data Sheet provided by NOS.

Q: Are these predictions compliant with the new Daylight Savings Time rules for ...?

A: XTide relies on the de facto standard time zone database to handle Daylight Savings Time. XTide's results will obey the new Daylight Savings Time rules if and only if the version of zoneinfo installed is sufficiently new. See System Requirements.

Q: I am doing some historical research and need to project what the tides at Mumble Foo Bar would have been a long long time ago.

A: This is generally ill-advised.

For years 1700 and later, you can install XTide on 64-bit Linux and run the predictions with no special effort, but without some form of validation there is no telling how large the error could be.

The perishability of tide data for a given location varies depending on how quickly the local topography changes. Some places go rotten in less than a decade. All locations are impacted by global sea level change, which becomes significant in less than a century.

Over even longer spans, the physics start to go wrong. Some of the astronomical "constants" used in the U.S. method of tide prediction really aren't constant; they change very slowly. For example, the speeds of harmonic constituents change. We are still using constant speeds that were calibrated for the year 1900. When you change the speeds of the harmonic constituents, it changes everything. As we get too far away from 1900 in either direction, eventually the model collapses and the results are garbage. As far as I know, nobody has done an analysis to determine exactly when this occurs.

When this happens in the future, we can just update the speeds and generate fresh harmonic constants that work within the new model. But we can't do that for historical predictions because we don't have the water level observations from that period in history to derive the harmonic constants. We have no choice but to use the physics of 1900, with data derived from observations in 2000, to extrapolate back to whenever, and hope that we haven't pushed the model too far.

It is technically possible to get XTide to make projections back to 1 AD (see Appendix A for details). However, the credibility of projections for anywhere reaches zero well before you get back to 1 AD. So please don't ask for BC support.

Q: I live outside of the U.S. and my location is no longer supported. What happened?

A: Many data were purged after a legal threat from the U.K. Hydrographic Office (UKHO) in January 2001. I ended maintenance of the non-U.S. data that replaced them for different reasons in early 2012.

Legacy data

Back in the old days, the collection of hydrographic data was done almost exclusively using public funds. The resulting harmonic constants were treated as scientific results, published, and distributed on request from an international data bank. Data were shared openly, and it was not a big deal. But in the late 20th century, a wave of privatizations occurred, and harmonic constants became the intellectual property of the collecting agencies.

You wouldn't think it possible to "un-publish" data that were distributed with considerable freedom at one time. Nevertheless, the international data bank was abolished, the Table des Marées des Grands Ports du Monde was withdrawn from publication, and I was coerced into removing the associated data from the harmonics files. [And then, ten years later, the Supreme Court of the U.S. ruled 6-2 that works can be removed from the public domain after the fact.]

Under the circumstances of privatization, it would have been reasonable to keep newly generated data secret; but to lay claim to the old data that were once shared in the spirit of scientific openness was, in my opinion, wrong. It was a disservice and dishonor to all of us who had accepted those data on good faith, maintained them, and added value to them, to end up accused of copyright infringement. I regret having spent days with my world atlas assigning coordinates and time zones to interesting faraway places, and I grieve for the knowledge that has vanished into the black hole of trade secrecy.

Although only the UKHO made an issue of it, the fact that they did sufficed to "poison" all of the International Hydrographic Office (IHO) and Table des Marées des Grands Ports du Monde (TMGPM) data for every country. We could no longer assume that we had permission to use any of them. So in January 2001, all of the data that arrived via the IHO or the TMGPM were removed from the harmonics files.

Renaissance and decline

In the years immediately following, I received cooperation from organizations in several countries to supply data or to clarify terms of use for data they had already published. Those terms allowed for free non-commercial use. That did not satisfy the Debian definition of "free," so for packaging purposes, the non-U.S. data had to be segregated from the public domain U.S. data. Thus, the "non-free" harmonics file came about.

Contributions of otherwise unpublished data then ceased. In 2009, the harmonic constants for Germany—which, being derived from time serieses that only minimally met the requirement, were never that hot—disagreed significantly with authoritative predictions and were neither reparable nor replaceable. By that time it had become clear that maintaining the data for one country once a year was quite enough work, and I had no time left to spend on non-free data anyway.

In 2010, I received a message from Department of Justice, Canada that I interpreted as a polite request to beef up the warnings against commercial use of the harmonic constants I had generated. (Ironic, since I had done only a fraction of Canadian stations to begin with.) After that, however, I was frequently contacted by iPhone and Android app developers wanting someone to explain, interpret, justify, and even enforce (against their competition) the terms of use on the non-free data, or who had already appropriated the data and now wanted training in how to exploit it. I spent a lot of time telling people things that they didn't want to hear, and the number of free or open-source apps that resulted was approximately zero.

As a result of the combination of lack of time, commercialism, and abuses, I decided in early 2012 to officially end maintenance of the non-free data set. Anyone interested in generating new harmonic constants from published data can find information and a list of data sources here. In an ideal world, the data collecting organizations themselves would publish harmonic constants directly in TCD format using the tools available from https://flaterco.com/xtide/files.html. The irrational legal technicalities of how to propagate "non-free" license terms through derivative works, Linux distributions and app stores, and across national boundaries, would then become a non-issue.

Q: I want to change the end time of a tide graph but the settings that I make have no effect.

A: This is Quirk #2. In graph mode, the end time is determined by the applicable width and aspect, not the other way around. Thus, neither the –e switch nor the compiled-in defpredictinterval constant have any effect in this case. In the interactive client, you can resize the window as you would any window and change the aspect from the Options menu. The applicable command-line switches are –gw for X-windows or PNG formats, –tw for text format, and –ga. For more details, refer to "Customizing XTide."

Q: The text in XTide windows uses uglyfont.

A: You can change the fonts using –fn, –gf, and –mf or the corresponding resources. However, to use FreeType fonts, XTide must be built with Xaw3dXft.

If XTide is built with Xaw3dXft, font names given to XTide must be in fontconfig format (e.g., "Helvetica-10"); otherwise, they must be in the traditional XLFD (e.g., "-*-helvetica-*-r-*-*-10-*-*-*-*-*-*-*").

Q: I applied a changed setting in the control panel, but it had no effect.

A: Settings made using command line switches override settings made in the control panel. In order to see an effect from changes applied in the control panel, XTide must be run without conflicting command line switches. In addition, font changes require a restart to become effective.

Q: When I run xttpd, it exits immediately with no errors to tell me what went wrong.

A: When executed, xttpd immediately disassociates itself from your terminal and starts logging all diagnostics to syslog. So look in your system logs. On an init system, you will find these someplace like /var/log or /var/adm/log. On a systemd system, you have to say (as root) journalctl -b -p debug --no-pager to dump the log.

Q: I always get a warning about "using obsolete time zone database."

A: Please see the System requirements section for details of what this means and what you can do to fix it.

Q: How do I switch from tide to current predictions or vice-versa for a given location?

A: Alas, although the two are clearly connected in the physical world, they are unrelated from the perspective of XTide. Even for the same location, tide predictions and current predictions require two completely separate data sets, and rarely will you get both. If current predictions are available for a location, they will appear in the location list with the word "Current" at the end of the name.

Q: What are bogo-knots?

A: If you are still seeing bogo-knots, then you are definitely using obsolete data and an obsolete version of XTide, or accessing a web site that is using obsolete data and an obsolete version of XTide. I am not the maintainer of any such web sites, and I recommend upgrading to XTide 2, which will barf all over any harmonics files that still contain "bogo-knots."

Q: First it says high tide is at 3:15 PM but then when I run it again it says 3:14 PM.

A: XTide's precision is plus or minus one minute. The behavior that you witnessed is normal.

Q: Has this been ported to Windows / PalmOS / anything but Unix?

A: Yes, to varying degrees. Please see the ports page.

Q: Xttpd sucks! Can't XTide work with PHP?

A: A number of people have expressed interest in getting XTide to work through PHP. Thus far I have just been introducing them to each other through e-mail and waiting for cool things to happen. There is now a WordPress plugin by Mir Rodríguez.

Q: The tides for my location are totally wrong!

A: Unfortunately, there have been some problems recently with data sets being assigned the wrong meridians upstream. The symptom is that all predictions are shifted earlier or later by the same number of hours. If you can verify that this has happened by comparison with published tide tables (available at http://tidesandcurrents.noaa.gov/), please report the problem for corrective action.

Q: The tides for Mumble Foo Bar are obviously bogus because they have too many high tides on this day / only one high tide on this day / tides that are just a few minutes apart.

A: That is not necessarily a problem. Some places really do have only one tide cycle per day. Others generate "extra" tides when the tidal forces align in such a way as to produce a "double" high or low tide or a temporary reversal near mid-tide. These extra tides can be arbitrarily close together. Official predictions might omit them, but XTide faithfully reports all maxima and minima that it finds.

Legacy data contain some data sets in which harmonic constants were generated for subordinate stations by munging the constants of a reference station. This operation was fragile and sometimes it led to spurious maxima and minima. The fix is to upgrade to the latest data, which contains no "munged" data sets.

Q: I have five constituents and some seasonal corrections for my location. Can you get this to work?

A: XTide is not presently enabled to handle seasonal corrections directly. To my knowledge, seasonal corrections are only used in publications by the British Admiralty that do not allow redistribution of data, so the value of providing better support for them in XTide would be marginal at best. However, if you have legal access to such data and are determined to use it with XTide, it may be possible to synthesize values for long-term constituents to "approximate the approximation." A spreadsheet for doing this is available from https://flaterco.com/xtide/files.html#experts.

It might also help to enable constituent inference in XTide. This can be done from the control panel or using the infer setting.

General tide related questions

Q: I have a tide watch that only goes through the year 1999. What year could I set it to that would be the same as this year?

A: Sorry. It just doesn't work like that.

Q: Is there a set time advancement each day for the next high and low tide? Does it always repeat 12½ hours later?

A: No. The 12 hour 25 minute cycle is literally only a first-order approximation. Most tide predictions involve twenty to thirty terms, and some require over a hundred. The 12:25 cycle is just the most dominant term.

Q: Somebody gave me a tide clock, but the instructions say it only works on the east coast. How can this be?

A: "Dumb" tide clocks assume that the 12 hour 25 minute cycle mentioned in the previous question is a good enough approximation. For the west coast, it isn't. The following tide graphs illustrate the differences between east and west coast tides. The high and low tide times that would be indicated by a "dumb" tide clock are shown with vertical yellow lines. San Francisco shows a 2-hour discrepancy on the lower high tide.

Emulation of dumb tide clock for Bangor, Maine

Emulation of dumb tide clock for San Francisco, California

Q: Why do the high and low tides have such different levels to them on any given day? Does it actually coincide with the amount of pull exerted by the phase or closeness of the moon?

A: The tides do not coincide too closely with the moon. While the moon produces most of the force that drives them, the exact tide levels result from the sloshing around of huge amounts of water, the effects of the shape of the coastline, and things like that.

Q: If it's high tide here, is it low tide in [faraway place]?

A: It's hard to infer anything over large distances since localized effects can have a huge influence on tides.

Q: What does the zero (0) on a tide chart represent?

A: Tide heights are given relative to the "datum" which in most cases is one of several benchmarks corresponding to low tides of varying extremeness. The preferred benchmark in the U.S. is Mean Lower Low Water (MLLW). The odds of the predicted tide getting below MLLW on any given day are about half. The preferred benchmark in the Netherlands is Mean Low Water Springs (MLWS). MLWS is lower than MLLW. The predicted tide will get below MLWS on average only about twice a month. The preferred benchmark in Germany is Lowest Astronomical Tide (LAT). LAT is the lowest tide predicted over a 19 year period. The predicted tide will not get below LAT in that 19 year period, and is unlikely to get below it by any significant amount ever.

In harmonics-dwf, some U.S. locations for which a MLLW benchmark was unavailable use an estimated value of MLLW that is derived from the predictions. These estimates tend to yield predictions that differ from National Ocean Service published tables by (0.1 to 0.2) ft. Older versions of harmonics-dwf used LAT for these stations, which of course yielded much larger discrepancies.

For more information on datums, read the National Ocean Service publication Tidal Datums and their Applications.

Q: Why is it that the tides two miles from here are an hour different than the tides here? If the tidal bulge follows the moon at 1,000 miles per hour, how can the difference be so great?

A: When the water tries to follow the moon, it runs up against a lot of obstacles, including its own inertia, the shape of the coastline, and the resonances that are set up by the continual tidal motion. In some cases the tides are fighting a permanent current, e.g., going up a river, and this slows down the tidal crest. The result is that the tides at any one place at any given time don't have a whole lot to do with the moon any more.

Q: Why are there two high tides per day, anyway? How is this possible?

A: The standard simple answer to this question is that the water on the side of the earth opposite the moon bulges out due to decreased lunar gravity in the same way that the water on the side of the earth nearest the moon bulges out due to increased lunar gravity. This is counter-intuitive in that one might expect all of the water to just rush over to the side where the moon is. To explain this, I quote from "Our Restless Tides," a NOAA tutorial at http://tidesandcurrents.noaa.gov/restles1.html:

To all outward appearances, the moon revolves around the earth, but in actuality, the moon and earth revolve together around their common center of mass, or gravity. The two astronomical bodies are held together by gravitational attraction, but are simultaneously kept apart by an equal and opposite centrifugal force produced by their individual revolutions around the center-of-mass of the earth-moon system. This balance of forces in orbital revolution applies to the center-of-mass of the individual bodies only. At the earth's surface, an imbalance between these two forces results in the fact that there exists, on the hemisphere of the earth turned toward the moon, a net (or differential) tide-producing force which acts in the direction of the moon's gravitational attraction, or toward the center of the moon. On the side of the earth directly opposite the moon, the net tide-producing force is in the direction of the greater centrifugal force, or away from the moon.

Q: What does "slack water" mean?

A: This and many other terms are defined in the NOAA tide glossary.

Q: I have a theory that [random phenomenon] is related to tidal forces, but I am landlocked. Can you, like, predict the "tides" for [landlocked location]?

A: There is no support for this in XTide (ocean tides have only the vaguest connection to latitude, longitude, and the position of the moon), but you can find relevant information by searching the web for "land tide."

Q: I want to write my own tide predicting program. Can you provide a SIMPLE explanation of the tide-predicting function?

A: The tide prediction function is fairly simple, requiring only a cosine function. The piles of code surrounding it in XTide are to optimize the process of finding maxima and minima. This can be done less optimally with significantly less code and effort (as early versions of XTide did).

Here is the BASIC pseudocode to generate the tide height or current velocity for a specified time point:

Height = Datum
for a = 1 to numconst
Height = Height + amplitude[a] * nodefactor[a] * cos (speed[a] * time + eqarg[a] − phase[a])
next a

The different quantities referenced are:

  • From the data set for a station:
    • The Datum—also called Z0—is a constant that is provided with each data set to calibrate the heights of tides relative to whatever is considered to be "zero," or to calibrate the velocities of currents against an actual velocity of zero. Without this constant term, the results of the equation would have a range centered on zero. It is provided in units of length for tides or units of velocity for currents.
    • amplitude[a] is the first of two values given for each constituent in a data set. It is provided in units of length for tides or units of velocity for currents.
    • phase[a]—also called the epoch—is the second of two values given for each constituent in a data set, and is expressed in angular units (degrees, radians, or cycles).
  • Global values not contained in the data set for a station:
    • speed[a] is the frequency of the constituent, often expressed in degrees per solar hour, but possibly in cycles per hour or even (gasp!) hertz.
    • nodefactor[a], the node factor, is an amplitude multiplier given for each constituent to adjust for long-term effects on the amplitudes. In the U.S. system, these are tabulated on a yearly basis, so you could write it as nodefactor[a][year]. Elsewhere, they are usually generated at a finer granularity or on demand for the middle of the prediction interval chosen.
    • eqarg[a], the equilibrium argument, is a phase adjustment given in angular units for each constituent to adjust for long-term effects on the phases. They are tabulated on a yearly basis.
  • Time, of course, is relative. If speed is in degrees or radians per X, then time is in X since the beginning of the year. What constitutes the beginning of the year depends on the meridian of the data set. The phases are calibrated such that time is measured from January 1 00:00 in the time zone specified by the meridian. Traditionally, the meridian is chosen to be the local standard time of the location in question to make life easier on simple tide prediction programs that don't mess with time zones or summer time adjustments. However, these days it is simpler to calibrate everything to UTC so that all the meridians are zero, and let the tide prediction program apply time zones after the fact.

The speeds, equilibrium arguments, and node factors for arbitrary constituents and time periods can be generated using Congen.

Business questions

Q: I want to license XTide so I can build a commercial product around it.

A: XTide is released under the terms of the GNU General Public License. This FAQ about the GPL may be applicable to you.

XTide has been used by commercial packages "at arm's length," to use the wording of the FAQ cited above, but I have never licensed it by any terms other than the GPL, nor have I ever offered any kind of warranty or service that one might expect if it were licensed commercially.

PLEASE NOTE: The question whether you can use XTide is completely separate from the question of whether you can use the tide data (harmonics files). In general, data for U.S. ports are public domain, while others are for non-commercial use only or subject to restrictive copyright. Read the boilerplate for details.

Q: I have a lot of specific questions about the GNU General Public License and/or want a ruling that my specific plan is OK.

A: Please read the GPL FAQ, available here. If that does not answer your question, the people to ask are at licensing@fsf.org.

Q: I would like to talk to you concerning the use of your stuff in our upcoming product. Please call me at your convenience. [#include email legal disclaimer]

A: Your questions have already been answered here and maybe here. There is nothing else to talk about.

Q: I really don't understand the whole purpose of the GNU license. Why should I have to reinvent the wheel just because I won't publish my sources?

A: XTide is free software. The GPL gives you the choice between respecting that freedom and passing it on, or reinventing the wheel. Some additional background on the rationale behind the GPL is available from the Free Software Foundation.

Q: We are a not-for-profit organization and we want to sell calendars with predictions from your web site. Is that OK?

A: Firstly, it's not my web site. See Question 1. Secondly, all predictions for places outside the U.S. are for non-commercial use only (i.e. you can't sell them no matter what your tax status is). Lastly, if you do want to sell calendars containing predictions for the U.S., you must include all of the "NOT FOR NAVIGATION" disclaimers and agree to accept full liability in case someone has a problem.

Legalities aside, my opinion has always been that people who are selling tide predictions have no business selling anything that is not directly certified by the National Ocean Service. Beggars can't be choosers, but when people are paying for something, they have a right to hold you to a higher standard.

Q: I have a great idea to make money selling tide predictions, but I'm not good with technical stuff, so would you just do this for me...

A: No.

Q: I already make money selling tide prediction products, but your stuff is better, so would you just do this for me...

A: No.

Q: I just put up a fabulous website that serves up XTide output surrounded by banner ads that make me tons of free money. Would you please link to it?

A: No.

Q: Hey, that previous guy had a great idea. Would you please install XTide on my web server for me?

A: No.

Q: I'm a consultant being paid to install XTide. I'm having a million problems with it, but I can't describe them accurately because I have never used Linux before. I think XTide must be really broken. Please fix all of my problems.

A: Sorry, I can't do that by email.

Q: I need to do [poorly researched brainstorm having something to do with tide prediction]—how much would you charge in consulting fees to help me do it?

A: It's moot. Your plan won't work for one or more of the following reasons:

  • You think that it's possible to predict tides for arbitrary locations based on just the latitude and longitude. It's not.
  • The harmonic constants that you plan to use are either unobtainable or encumbered in ways that make what you want to do with them illegal.
  • You think that harmonic constants can be burned into the firmware of an embedded device and never need maintenance. They can't be; they need to be updated regularly.
  • You think that you can cut corners with a simple tide clock and still get tide predictions that match those published by NOAA. You can't.

Q: Congratulations! XTide has been added to some online directory of software packages. Please verify that the information on XTide is correct and keep it updated.

A: Congratulations! No. You do it.

Academic questions

Q: How should I cite XTide within publications?

A: The web site is the best thing you can cite. For a general reference to XTide, I suggest the following, with the current date.

[1] David Flater. XTide. https://flaterco.com/xtide/. 2005-07-04.
If you are using specific predictions from XTide rather than just XTide in general, then you should cite the specific version of XTide and the specific data file that you used. In this case, it would be appropriate to use the date indicated in the changelog for that version of XTide and the revision date of the data file.

[2] David Flater. XTide version 2.8.2. https://flaterco.com/xtide/. 2005-01-06.

[3] harmonics-dwf-2005-06-05-v2. Available from https://flaterco.com/xtide/files.html, 2005-06-05.

Questions that you should have asked, but didn't

Q: What is the difference between a reference station and a subordinate station?

A: The following information was copied from NOAA's web site on 2007-02-17.

The publication of full daily tide predictions is necessarily limited to a comparatively small number of stations. These stations are referred to as "reference stations". Tide predictions for more than 3000 other locations, referred to as "subordinate stations", can be obtained by applying specific differences to the daily tide predictions for one of the reference stations. [...]

Caution: The time differences and height ratios used to calculate predictions at subordinate stations are derived from a comparison of simultaneous tide observations at the subordinate station and its reference station. Because these adjustments are constant, they may not always provide for the daily variations in the actual tides, especially if the subordinate station is some distance from the reference station. Therefore, although the application of time differences and height ratios will generally provide reasonably accurate approximations, they cannot result in predictions as accurate as those listed for the reference stations, which are based on much larger periods of analysis.

In plain language, what you need to know is this: All subordinate station predictions are approximate. Tide predictions are always at best approximations of reality, but for subordinate stations that goes double.

Q: These predictions are nonsense—what is going on here?

Tide graph with a weird zigzag
2007-02-14 12:57 PM AKST   3.46 feet  High Tide
2007-02-14  3:00 PM AKST   Moonset
2007-02-14  7:08 PM AKST   Sunset
2007-02-14  9:06 PM AKST  -0.38 feet  Low Tide
2007-02-15  6:46 AM AKST   3.08 feet  Low Tide
2007-02-15  7:00 AM AKST   2.62 feet  High Tide
2007-02-15  9:07 AM AKST   Moonrise
2007-02-15  9:22 AM AKST   Sunrise
2007-02-15  1:46 PM AKST   3.46 feet  High Tide
Current graph with weird double-flood
2004-03-31  5:01 AM PST  -0.64 knots  Max Ebb
2004-03-31  5:49 AM PST   Sunrise
2004-03-31 10:06 AM PST   0.02 knots  Max Flood
2004-03-31 10:18 AM PST   0.00 knots  Slack, Flood Begins
2004-03-31 11:21 AM PST  -0.00 knots  Slack, Ebb Begins
2004-03-31  1:01 PM PST   Moonrise
2004-03-31  4:13 PM PST  -0.90 knots  Max Ebb

These are extreme examples of what can happen when the time differences and height ratios for subordinate stations don't "provide for the daily variations in the actual tides." Although in the average case the offsets might yield good results, in extreme cases they can yield nonsense results like tide events happening in an impossible order or a "low" tide actually being higher than the "high" tide right next to it. There is nothing XTide can do to rationalize these paradoxes, and the tide levels that are interpolated between paradoxical events are essentially garbage.

Q: Where can I find tons of information about tides that is both more authoritative and better written than this FAQ?

A: http://tidesandcurrents.noaa.gov/education.html


Quirks, limitations, and bugs

Lobster boat and the big ocean, Ogunquit, Maine, 1998-06-08.

Quirks to be aware of

  1. Graphs actually begin a little bit earlier than the nominal start time so that the specified start will appear immediately to the right of the labels for the depth axis instead of being obscured by them.
  2. The effective end time for graph and clock modes is entirely determined by the start time, the width, and the aspect. If an end time is also specified by the user, it is ignored.
  3. XTide uses shorter descriptions for the tide events listed across the bottom caption line in tide graphs whenever the descriptions get to be longer than the timestamps. Consequently, changing the time format setting to something more concise causes the descriptions to get shorter too, which is what you want. However, this behavior can result in cosmetic inconsistencies; e.g., with default settings, "Mark Rising" is matched by "Mark" instead of "Mark Falling," because the one additional letter puts it over.
  4. The –o command line switch causes output to be appended to the specified file instead of overwriting it as is the generally accepted custom.
  5. While XTide-specific command-line arguments can be concatenated with their switches or not, the arguments to standard X11 switches sometimes must be separate to work. Affected switches include –display, –fn, and –geometry.
  6. What XTide does about minimum current events at subordinate stations might not be what you expect. See Appendix B for details.

Known limitations

  1. RGB color specs (rgb:N/N/N) in sizes other than 24 bits (rgb:hh/hh/hh) generally will not work.
  2. All timestamps have a precision of plus or minus one minute.
  3. XTide locates tide events to an accuracy of plus or minus one minute. This refers only to the prediction model, not to how well the model agrees with reality.
  4. URLs assigned to specific locations by the xttpd web server are rather transient and will change whenever the harmonics files are updated. The xttpd web space will remain internally consistent, but hyperlinks from outside pages will be screwed.
  5. The time scale for stations claiming to be in UTC is not strictly speaking UTC since it does not implement leap seconds.
  6. If a subordinate station has absurd offsets that cause low tides to become higher than high tides, the upper and lower bounds reported by stats mode may be incorrect.
  7. When specifying location names on the command line, multiple data sets having the same name cannot be distinguished, and it is not deterministic which one you will get.
  8. XTide is untested and probably dysfunctional on any platform where time_t is a non-integral type. It would probably still work with --enable-time-workaround.
  9. XTide assumes that the first 256 characters of every font agree with ISO-8859-1 (except under DOS).
  10. Semitransparent style makes no sense in formats that don't support opacity (text and PseudoColor X-windows).

Known bugs

  1. If the control panel is resized, dismissed, and then shown again, its buttons are missing. Cause of bug: Don't know. Workaround: Close the control panel using the window manager (e.g., hit the × in the upper right corner) and then show it again. The control panel retains its new size but the buttons reappear.
  2. Some of the dialog windows cause harmless but annoying toolkit warnings when you dismiss them. Cause of bug: Don't understand what the toolkit grabs are doing. Workaround: Ignore warnings.
  3. Line width in line graphs isn't maintained when the slope of the graph becomes drastic. Cause of bug: Need better algorithm for drawing line graphs. Workaround: Set the aspect higher.
  4. Buttons will sometimes shift out from under the mouse pointer and get "stuck on." Cause of bug: (1) button moves due to changing geometry of other things in the box, leading to (2) button shifts out from under the pointer, which triggers (3) bug in Athena Widgets where the button release event gets lost. Workaround: As needed, click on the stuck button to un-stick it. This problem can be prevented in the control panel by specifying a monospace font with the –fn switch, which avoids (1). The bug is less likely in other windows.
  5. The analog tide clock icon flashes when it updates, and doesn't update at all under some window managers. Alternate symptom: Tide clocks crash the window manager at random. Cause of bug: Window managers don't expect icons to keep changing and aren't designed to handle it properly. Workaround: Use a window manager that doesn't suck.
  6. Dialog boxes don't behave like you would expect when you hit the Enter key. Cause of bug: Athena widgets use multi-line buffers even for one-line fields. Workaround: Don't hit Enter.
  7. Syslog messages generated by xttpd have timestamps in UTC or random time zones instead of local time, which is highly confusing in a log that is otherwise in local time. Cause of bug: Design defect of syslog(): Every program logs in whatever time zone it happens to be using at the time instead of a standard zone. XTide needs to adopt the time zone of each station to generate predictions for it. Workaround: none.
  8. The location chooser depends on a station naming convention to determine which stations are currents. If that convention is not followed, dots may be drawn in the wrong color. Cause of bug: Design defect of libtcd: libtcd doesn't let you know whether you are looking at a tide station or a current station until after you load it. Workaround: Ensure that "Current" appears in the station name if it's a current, and not otherwise.
  9. When XTide is linked with Xaw3d or Xaw3dXft, text dialog boxes reachable from the Options menu (save filename, mark level, aspect) and control panel may have 2-color bitmap borders instead of gray-shaded borders. Cause of bug: For reasons unknown, the "threeD" widget owned by asciiTextWidget is inaccessible from the application level, preventing XTide from setting its beNiceToColormap resource to False. Workaround: Add XTide*beNiceToColormap: False to ~/.Xresources.


About harmonic constants and sub station corrections

Portland Head Light

About harmonic constants and sub station corrections
(What to do if your location isn't listed)

As was explained in the introduction, tide predictions for a given location cannot be conjured out of the void—you need to get some special data for each and every location for which you want to predict tides. XTide reads these data from harmonics files.

The harmonics file available at https://flaterco.com/xtide/files.html#harmonicsfiles contains all data for U.S. stations that were available from the NOS web site as of the last update. I update it once a year.

For various reasons, I no longer maintain data for stations outside the U.S. Methods by which non-U.S. stations or unsupported U.S. stations can be added are described below; but first, some important definitions.

National Ocean Service tide station at Bar Harbor, Maine

Harmonic constants (reference stations)

Harmonic constants are created by analysis of regular water level readings taken by automated tide stations like the one pictured here. A tide station whose predictions trace directly to harmonic constants that were derived from water level readings for that same station is called a reference station.

A set of harmonic constants provides an amplitude and a phase (or "epoch") for various harmonic constituents with names like M2 and K1. The number of constituents used for a given station can vary from a few to over 100. However, if you get six or fewer constituents then you are probably dealing with "simplified" harmonic constants. Simplified harmonic constants limit the accuracy that can be achieved for predictions because the less significant constituents have been thrown away. If simplified harmonic constants must be used, it is a good idea to enable constituent inference in XTide.

Some Admiralty data include nonharmonic adjustments that are not supported by XTide. A spreadsheet has been contributed to convert Admiralty seasonal corrections to approximate long-term constituents that XTide can use. However, for "S.W. CORRECTIONS" (shallow water corrections) called f4 and f6 there really is no support yet.

Offsets (subordinate stations)

A subordinate station is a tide station whose predictions are obtained by applying corrections to the predictions generated for a reference station, i.e., a station for which we have good harmonic constants. The words 'corrections,' 'differences,' and 'offsets' are used interchangeably when referring to subordinate station data.

While harmonic constants can be hard to get, you should be able to get offsets with relative ease from a local boating magazine, chartbook, yacht club, or marine authority.

There are many different flavors of offsets for subordinate stations. At this time, XTide supports all commonly appearing flavors except for the Admiralty one that has different height differences depending on the time of month. The following rare and freakish sorts are not supported: those that use different offsets depending on whether the flood at the reference station crossed some threshold; those that rely on more than one reference station; those that use different offsets for higher high or low water versus lower high or low water; currents that use a regular tide station as reference, or vice-versa.

Some putative sets of harmonic constants for subordinate stations were created by mangling the constants of a reference station to approximate the results of applying corrections. Such mangled data only junk up the database and should be avoided.

Adding subordinate stations using tideEditor

If you find suitable offsets, you can add them to harmonics.tcd using the tideEditor program available from https://flaterco.com/xtide/files.html#extras. There are two other ways to do it, as described below under "Importing batches of harmonic constants and offsets," but tideEditor is most expedient for the non-expert.

First, always make a backup copy of whatever you are about to modify.

TideEditor version 1.4 takes the name of the file to modify as the command-line argument.

bash-3.1$ tideEditor whatever.tcd

When you start tideEditor, you get a map of the world. Point at the location where you want to add a subordinate station and right click.

You will get a prompt asking "Will the new station be a reference station or a subordinate station?" Choose Subordinate.

You will get a prompt saying "Please select the new reference station." Use the pull-down list to select the reference station and click OK.

You will then get a window with the tabs General, Verbiage and Offsets, initially showing General. On the General tab, the Reference Station, Latitude and Longitude fields will be pre-filled based on your previous actions. If you don't know the correct latitude and longitude, just estimate the coordinates as best you can.

The other fields that you MUST fill in are as follows:

  • Station Name: Enter the name of the new subordinate station.
  • Time Zone: Use the pull-down to set the time zone (select the major city for the applicable region). The timezone attribute is only used to choose the time zone in which to render output for the location. In the majority of cases this will be the same as for the reference station.
  • Level Units: Select feet or meters for tides, knots for currents.

All other fields on the General and Verbiage tabs are optional. Descriptions of the other fields are obtainable using the question mark tool thingy ( [image]).

The Offsets tab has the following fields.

  • Minimum Time Add. The time adjustment for low tide / max ebb. It is expressed as an integer that is hours times 100 plus minutes, so for −0:20 (negative 0 hours, 20 minutes) you would write −20, and for 1:40 (positive 1 hour, 40 minutes) you would write 140. If you don't have this, leave it blank.
  • Minimum Level Add. A value, in the units identified by Level Units, that is added to the tide level or current velocity predicted at low tide or max ebb. If you don't have this, leave it blank.
  • Minimum Level Multiply. A multiplier for the tide level or current velocity predicted at low tide or max ebb. If you don't have this, leave it blank.
  • Maximum Time Add, Level Add, and Level Multiply are analogous, but correspond to high tide / max flood.
  • Flood Begins. Another kind of "Time Add" used only by currents to adjust the time of the slack preceding a flood. If you don't have this, leave it blank. If it got initialized to zero, make it blank.
  • Ebb Begins. Analogous to Flood Begins.

Notations used to describe corrections will vary:

Notation | Translation
−0:20 | Time Add −20
1 23 | Time Add 123
*1.07 | Level Multiply 1.07
+0.4 | Level Add 0.4
(*0.65+0.3) | Level Multiply 0.65, Level Add 0.3

If you were not given separate corrections for max and min, set both the max and min values to whatever you got. For example, if you get

Head Harbor, Isle au Haut    -0:20   (Portland)

then you should set both Minimum Tide Add and Maximum Time Add to −20.

Special cases:

  • If you don't get slack offsets (floodbegins, ebbbegins) for a current station, OMIT those fields! When slack offsets are omitted, XTide will interpolate a reasonable value. But if you specify zero, you get zero—even if that's unreasonable with respect to the specified max and min.
  • If your reference station is in a different time zone, you may need to alter the time offsets to REMOVE compensation for the time zone difference. NOAA had a practice of including the time zone differential in the offsets, but in XTide, the offsets are independent of the time zone.

When finished, click OK. When you quit tideEditor, your new station will be saved in the updated TCD file.

Adding reference stations using tideEditor

To add a reference station with tideEditor, the general process is similar to adding a subordinate station, but the data to enter are more obscure and there are more opportunities for the non-expert to get stuck.

When you get the prompt asking "Will the new station be a reference station or a subordinate station?" choose Reference.

Instead of "Offsets," the third tab in the dialog is now "Constituents."

  • Datum Description. Choose Mean Lower Low Water or whatever is the description of the datum that you have received. If you don't know, you can proceed without setting it.
  • Datum Value. Enter the datum (sometimes known as Z0) in the level units that were specified on the first tab.
  • Meridian. This is a fixed offset from UTC to which the amplitudes of the harmonic constants were calibrated. Opportunity for trouble: You have to know the right answer for the data that you received. Sometimes it will be local standard time for the location; sometimes it will be zero. The format is hours times 100 plus minutes, with positive values being east of Greenwich and negative values west.
  • Amplitude and Epoch for many constituents. Scroll down to see all of the constituents that are supported by the harmonics file. Opportunity for trouble: Different countries sometimes use different names for the same constituents, or worse yet, use the same names for different constituents. XTide's naming scheme is just yet another one that had to deal with these ambiguities and conflicts. For the technical definitions of the constituents used in XTide's default harmonics files, refer to the Congen package.

Importing batches of harmonic constants and offsets

All pretense of user-friendliness stops here. If you want to do large numbers of stations without lots of manual data entry, you have two options, both of which require a higher level of computer literacy than is demanded by tideEditor.

  1. The good way is to install Harmbase 2 and either write an import procedure for your data format or convert your data into one of the formats that it can already import. Harmbase 2 uses PostgreSQL to manage the data and merely exports to the TCD format.
  2. The evil way is to convert your data into the legacy .txt and .xml file formats that XTide used in the bad old days and then use tcd-utils to convert that to TCD.

Deriving harmonic constants from water level data

Anyone with a Linux PC, enough determination to install Octave, enough skill to convert data from one format to another, and enough data—at least a year's worth of hourly water level measurements—should be able to derive harmonic constants using the Harmgen package. Harmgen produces results in the form of an SQL insert statement that loads the new station into Harmbase 2 using XTide's constituent naming scheme. Those with sufficient background and a reason to do it can change the constituent set, but the new constituent definitions must be harmonized between Harmbase and Harmgen.

There is no added complication from multi-year time serieses. Harmgen accounts for the equilibrium arguments and node factors for each year and minimizes the error across the entire span of the time series.

Under the best of circumstances, predictions from harmonic constants derived this way can be expected to differ from authoritative predictions by 20 minutes or so. But if the authorities are using a nonharmonic method of tide prediction—or if you messed up—the discrepancies could be worse. It is up to you to do quality assurance.

Details on the operation of Harmgen can be found in that package's README file.

List of web sites with traceable data

This list is probably neither complete nor current. These are just the data sources that have been brought to my attention.

Harmonic constants:

  • Italy: I had this link, but I can't find anything there now. Maybe here?
  • National Ocean Service: Some locations outside of U.S. jurisdiction have historically been included along with the U.S. data.
  • Norway (simplified harmonic constants only)
  • Spain

Water level data:

  • Canada
  • Spain
  • France
  • U.K.
  • University of Hawai`i Sea Level Center (see also here or here)


Harmgen README file

https://flaterco.com/xtide/files.html#experts

$Id: README 6756 2018-01-15 16:06:54Z flaterco $

    harmgen:  Derive harmonic constants from water level observations.
    Copyright (C) 1998  David Flater.

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.

This package is available from
https://flaterco.com/xtide/files.html#experts.

Credits
-------

The math in harmgen.sh was based on an APL file contributed by Charles Read,
a professional mathematician and occasional sailor who made very short work
of the fearsome least squares analysis.  The subsequent extension to handle
multiple years was explained by Björn Brill.  The relevant emails are
included in the distribution for their educational value (files C_J_Read.txt
and Bjoern_Brill.txt).

Software prerequisites
----------------------

Required:  Congen (libcongen), available from
https://flaterco.com/xtide/files.html#experts.

Required:  Compatible version of Octave, available from
http://www.octave.org/.

  Some help on installing Octave from source is available at
  https://flaterco.com/kb/Octave.html

Optional:  Harmbase2, available from
https://flaterco.com/xtide/files.html#experts.  Harmgen is designed to
integrate with Harmbase2, but you don't need Harmbase2 if all you want is the
harmonic constants.

Hardware requirements
---------------------

The amount of memory needed for the least squares computation is proportional
to the product of the number of observations with the number of constituents.
A modern desktop PC with multiple gigabytes of RAM can easly handle hundreds
of thousands of observations and over 100 constituents.

Preface / caution
-----------------

The reliability of both the input and the output of Harmgen has to be
assessed rather than assumed.  A minimum-length time series, even one of high
quality, is unlikely to determine the long-term constituents with much
accuracy.  If the input data quality is low, the quality of results will also
be low.

Data requirements
-----------------

You will need, at a minimum, a year's worth of water level observations, at
least one per hour.  More years is better, to a point.  19 years is a
complete epoch; beyond that, the risks of using increasingly old data
probably exceed the benefits.  If you are in an area where silting, dredging,
or an earthquake has affected the behavior of the tides, the useful range may
be significantly shorter than 19 years.

Observations should be taken at periodic or random intervals.  It doesn't
matter if there are gaps, if the interval changes halfway through, etc.
However, a time series consisting of only the high and low tides is *not*
good enough.  One observation per hour is a reasonable minimum; ten per hour
is not unreasonable; more than ten per hour is unlikely to improve results.

This time series should be formatted the same as XTide's raw mode output,
with Unix time_t timestamps on the left (these are in seconds since
1970-01-01 00:00 UTC) and observations on the right:

902856260 1.088975
902859860 0.751052
902863460 0.511209
etc.

You will also need a Congen input file that defines the constituent set that
you want to use.  The distribution comes with three examples that you can use
as-is:

 congen_1yr.txt:   140 constituents, usable with at least 1 year of data.
 congen_5yrs.txt:  144 constituents, usable with at least 5 years of data.
 congen_9yrs.txt:  145 constituents, usable with at least 9 years of data.

The install process copies these three files into the pkgdata directory,
which normally is /usr/local/share/harmgen.

Length of time series versus available constituents
---------------------------------------------------

Harmgen does a basic check to ensure that the time series covers a long
enough span of time to make it possible to distinguish all of the available
constituents from each other.  This does not mean that the results will be
reliable, only that they might be.  If the time series is definitely not long
enough, Harmgen reports errors similar to the following.

  The time series of length 1.998558 average Gregorian years
  is too short to separate the following constituents from each other:
    3MKS2 (26.8701754 deg/hr) and 2NS2 (26.8794590 deg/hr)
      delta = 0.226053 rotations/year
    NLK2 (27.8860711 deg/hr) and 2N2 (27.8953548 deg/hr)
      delta = 0.226053 rotations/year
    MSL6 (88.5125831 deg/hr) and SNK6 (88.5218668 deg/hr)
      delta = 0.226053 rotations/year
    3ML8 (116.4807916 deg/hr) and 2MNK8 (116.4900752 deg/hr)
      delta = 0.226053 rotations/year

You must either get a longer time series or comment out one (or both) of each
pair of colliding constituents in the Congen input file.  The files
congen_1yr.txt and congen_5yrs.txt that are provided in the distribution were
both produced by commenting out constituents from congen_9yrs.txt to
eliminate collisions.

If a time series shorter than 1 year is used, long-term constituents cannot
reliably be determined through the analysis that Harmgen performs, and you
will get the following error:

  The time series of length 0.834948 average Gregorian years
  is too short to resolve SA (0.0410686 deg/hr, 1.000001 rotations/year)

To have any hope of obtaining acceptable results with a short time series,
the long-term constituents must be replaced with inferred values.  libtcd and
XTide provide a capability to infer some constituents when a station is
loaded, but the effectiveness of this feature when used in conjunction with
Harmgen and time serieses shorter than 1 year has not been tested.

The error checks described above are based solely on the earliest and latest
times appearing in the time series.  They will not save you if the time
series has enormous gaps.

If you want to ignore the errors and proceed anyway, use the --force
command-line option.

Compiling and installing harmgen
--------------------------------

bash-3.1$ ./configure
bash-3.1$ make
bash-3.1$ su
bash-3.1# make install

Harmgen is packaged with the popular and portable GNU automake, so all usual
GNU tricks should work.  Help on configuration options can be found in the
INSTALL file or obtained by entering ./configure --help.

The files that get installed are:

In ${exec_prefix}/bin:      harmgen (the actual application that you run)
In ${exec_prefix}/libexec:  harmgen.sh (script needed by the application)
In $(datadir)/harmgen:      congen_1yr.txt congen_5yrs.txt congen_9yrs.txt

By default, the three directories listed above resolve to /usr/local/bin,
/usr/local/libexec, and /usr/local/share/harmgen respectively.

Running harmgen
---------------

You must do 'make install' before running harmgen because the harmgen
application needs to find the harmgen.sh script in the libexec directory.

The harmgen program has three mandatory parameters:
  The name of the Congen input file
  The name of the time series input file
  The name of the output file

The --force parameter disables error stops.  The --maxconstituents and
--minamplitude parameters specify policy for discarding constituents, as
described in the next section.  All remaining parameters are for specifying
metadata that are simply passed through into the output.  They are all
optional; however, to get acceptable results, it is highly advisable to
specify at least the station name, units and timezone.

The time zone is specified with a zoneinfo identifier such as
:America/New_York.  There is no really good documentation on zoneinfo, so see
"List of likely choices for timezone" at the end of this README.

Usage: harmgen [--name "Station name"]
               [--original_name "Original station name"]
               [--station_id_context "Organization assigning ID"]
               [--station_id "ID"]
               [--coordinates N.NNNNN N.NNNNN]    -90..90 °N  -180..180 °E
               [--timezone "Zoneinfo time zone spec"]
               [--country "Country"]
               [--units meters|feet|knots]
               [--min_dir N]                       0..359 ° true
               [--max_dir N]                       0..359 ° true
               [--legalese "1-line legal notice"]
               [--notes "Warnings to users"]
               [--comments "Info about this station"]
               [--source "Harmgen using data from XYZ"]
               [--restriction "Public domain"]
               [--xfields "EtCetera:  Et cetera."]
               [--datum "Lowest Astronomical Tide"]
               [--datum_override N.NN]
               [--maxconstituents N]
               [--minamplitude N.NN]
               [--force]
               congen-input-file.txt
               time-series-input-file.txt
               output-file.sql

When executed, the harmgen program will do the following:

  (1)  Generate a file called "oct_input" containing the data needed
  by the Octave script.

  (2)  Invoke harmgen.sh, which runs the Octave script.  It may run
  for a long time and consume lots of memory with no visible
  progress.  In the end, the file "oct_output" is created.

  (3)  When the script exits, harmgen reads the contents of
  oct_output, makes final adjustments, and writes the output to
  output-file.sql.

The intermediate files "oct_input" and "oct_output" will be left laying
around so that you can inspect or reuse them if troubleshooting is needed.
Otherwise, to avoid confusion, please delete them before running harmgen
again.

Discarding constituents
-----------------------

Two command-line options allow you to set policy on discarding constituents.
They can be used together without conflict.

--maxconstituents N    Sort constituents by descending amplitude and retain
                       at most the top N of them.

--minamplitude N.NN    Discard constituents with amplitude less than the
                       specified number.

Using the new station
---------------------

If all you wanted was the harmonic constants, you can extract them from the
human-readable output-file.sql using a text editor and take it from there.
However, the output of Harmgen is designed to be used with Harmbase2, a
harmonic constant management package that handles all the details.  Harmbase2
is available from https://flaterco.com/xtide/files.html#experts.

To create a TCD file containing only the new station, you would load the
empty Harmbase2 schema, load the new station, and export:

bash-3.1$ createdb harmbase2
bash-3.1$ psql harmbase2 < harmbase2.sql
bash-3.1$ psql harmbase2 < output-file.sql
bash-3.1$ hbexport --optimize test.tcd

XTide is able to use multiple TCD files simultaneously, so you just need to
add the new TCD file to your HFILE_PATH:

export HFILE_PATH=/usr/local/share/xtide/harmonics.tcd:/home/somebody/test.tcd

If you want to go to the trouble of merging your new data into a distributed
TCD file, you just need to substitute that TCD file's database dump for the
empty harmbase2.sql schema:

bash-3.1$ createdb harmbase2
bash-3.1$ psql harmbase2 < harmonics-dwf-20*.sql
bash-3.1$ psql harmbase2 < output-file.sql
bash-3.1$ hbexport --optimize test.tcd

The most recent database dump is available from
https://flaterco.com/xtide/files.html#harmonicsfiles.

Caution
-------

The interface between Harmgen and Harmbase2 depends on canonical naming of
constituents.  If you rename constituents, modify constituent definitions or
create new ones in the input to Harmgen, you must make the same changes in
the constituents table of the Harmbase2 schema.  There is no way for
Harmbase2 to defend against semantic mismatches when all it gets is a name.
You just have to use the same definitions in both places.

Troubleshooting
---------------

1.  Harmgen dies with the following errors:
      sh: /usr/local/libexec/harmgen.sh: No such file or directory
      oct_output: No such file or directory

    Cause:  You didn't do 'make install' before running harmgen.

2.  libc aborts with a free() or invalid pointer error, Octave dies
    with "error: memory exhausted" or Octave gets killed after
    thrashing for a while.

    Most likely cause:  You ran out of memory.  There are three ways
    to fix this:

    1.  Reduce the number of constituents in the Congen input file.
    2.  Reduce the number of observations in the time series.
    3.  Add memory.

    Once you determine which constituents aren't going to get any
    amplitude you can delete those and start over with more observations.

3.  Predictions are off by some even multiple of hours.

    Possible cause #1:  Wrong timezone.  In this case, the predictions
    aren't actually *wrong*, they are just expressed in the wrong time
    zone (e.g., 4 PM Central Time is equivalent to 5 PM Eastern Time).

    Possible cause #2:  Wrong conversion of time series.  The
    timestamps in the time series file are expressed in seconds since
    1970-01-01 00:00 UTC.  If you did this conversion from 1970-01-01
    00:00 local time then everything will be wrong.

    Possible cause #3:  You changed the meridian in the SQL output
    from 0:00.  NEVER do that!  You are allowed to change the
    timezone, but DO NOT change the meridian from 0:00.

4.  Predictions are off by an average of 25 minutes.

    The predictions are actually off by 12 hours.  The most significant
    constituent of tides cycles in 12 hours 25 minutes, so in many cases a
    12 hour shift is easy to overlook.  See previous problem.

5.  The results are complete garbage.

    Witnessed with Octave 3.0.0.  Upgrading to Octave 3.0.1 solved the
    problem.

References
----------

Manual of Harmonic Analysis and Prediction of Tides.  Special Publication
No. 98, Revised (1940) Edition (reprinted 1958 with corrections; reprinted
again 1994).  United States Government Printing Office, 1994.

Computer Applications to Tides in the National Ocean Survey.  Supplement to
Manual of Harmonic Analysis and Prediction of Tides (Special Publication
No. 98).  National Ocean Service, National Oceanic and Atmospheric
Administration, U.S. Department of Commerce, January 1982.

List of likely choices for timezone
-----------------------------------

The following list is from an old version of zoneinfo.  For the latest, see
the data distribution available at https://www.iana.org/time-zones.

Legal values of timezone include, but are not limited to:

:Africa/Abidjan
:Africa/Accra
:Africa/Asmera
:Africa/Banjul
:Africa/Bissau
:Africa/Brazzaville
:Africa/Cairo
:Africa/Casablanca
:Africa/Conakry
:Africa/Dakar
:Africa/Dar_es_Salaam
:Africa/Djibouti
:Africa/Douala
:Africa/Freetown
:Africa/Johannesburg
:Africa/Kinshasa
:Africa/Lagos
:Africa/Libreville
:Africa/Lome
:Africa/Luanda
:Africa/Malabo
:Africa/Maputo
:Africa/Mogadishu
:Africa/Monrovia
:Africa/Nairobi
:Africa/Nouakchott
:Africa/Sao_Tome
:Africa/Tunis
:Africa/Windhoek
:America/Adak
:America/Anchorage
:America/Antigua
:America/Atka
:America/Barbados
:America/Belize
:America/Bogota
:America/Buenos_Aires
:America/Caracas
:America/Cayenne
:America/Chicago
:America/Costa_Rica
:America/Curacao
:America/Edmonton
:America/El_Salvador
:America/Ensenada
:America/Godthab
:America/Goose_Bay
:America/Grand_Turk
:America/Grenada
:America/Guadeloupe
:America/Guayaquil
:America/Guyana
:America/Halifax
:America/Havana
:America/Hermosillo
:America/Iqaluit
:America/Jamaica
:America/Juneau
:America/Lima
:America/Los_Angeles
:America/Martinique
:America/Mazatlan
:America/Mexico_City
:America/Montevideo
:America/Montreal
:America/Nassau
:America/New_York
:America/Nome
:America/Panama
:America/Paramaribo
:America/Port_of_Spain
:America/Port-au-Prince
:America/Puerto_Rico
:America/Santiago
:America/Santo_Domingo
:America/Sao_Paulo
:America/St_Johns
:America/St_Lucia
:America/St_Thomas
:America/Thule
:America/Tijuana
:America/Vancouver
:America/Winnipeg
:America/Yakutat
:America/Yellowknife
:Antarctica/Casey
:Antarctica/Davis
:Antarctica/Mawson
:Antarctica/McMurdo
:Asia/Aden
:Asia/Baghdad
:Asia/Bahrain
:Asia/Bangkok
:Asia/Calcutta
:Asia/Colombo
:Asia/Dacca
:Asia/Dubai
:Asia/Hong_Kong
:Asia/Jakarta
:Asia/Jayapura
:Asia/Kamchatka
:Asia/Karachi
:Asia/Kuala_Lumpur
:Asia/Kuwait
:Asia/Magadan
:Asia/Manila
:Asia/Muscat
:Asia/Phnom_Penh
:Asia/Pyongyang
:Asia/Qatar
:Asia/Rangoon
:Asia/Riyadh
:Asia/Saigon
:Asia/Seoul
:Asia/Shanghai
:Asia/Singapore
:Asia/Taipei
:Asia/Tehran
:Asia/Tokyo
:Asia/Ujung_Pandang
:Asia/Vladivostok
:Atlantic/Azores
:Atlantic/Bermuda
:Atlantic/Canary
:Atlantic/Cape_Verde
:Atlantic/Faeroe
:Atlantic/Madeira
:Atlantic/Reykjavik
:Atlantic/St_Helena
:Atlantic/Stanley
:Australia/Adelaide
:Australia/Brisbane
:Australia/Darwin
:Australia/Hobart
:Australia/Lord_Howe
:Australia/Melbourne
:Australia/Perth
:Australia/Sydney
:Europe/Amsterdam
:Europe/Belfast
:Europe/Berlin
:Europe/Brussels
:Europe/Copenhagen
:Europe/Dublin
:Europe/Gibraltar
:Europe/Lisbon
:Europe/Ljubljana
:Europe/London
:Europe/Madrid
:Europe/Moscow
:Europe/Oslo
:Europe/Paris
:Europe/Rome
:Europe/Zagreb
:Indian/Antananarivo
:Indian/Christmas
:Indian/Cocos
:Indian/Mayotte
:Indian/Reunion
:Pacific/Apia
:Pacific/Auckland
:Pacific/Easter
:Pacific/Efate
:Pacific/Fiji
:Pacific/Funafuti
:Pacific/Galapagos
:Pacific/Gambier
:Pacific/Guadalcanal
:Pacific/Guam
:Pacific/Honolulu
:Pacific/Johnston
:Pacific/Kwajalein
:Pacific/Majuro
:Pacific/Marquesas
:Pacific/Midway
:Pacific/Niue
:Pacific/Norfolk
:Pacific/Noumea
:Pacific/Pago_Pago
:Pacific/Palau
:Pacific/Ponape
:Pacific/Port_Moresby
:Pacific/Rarotonga
:Pacific/Saipan
:Pacific/Tahiti
:Pacific/Tarawa
:Pacific/Tongatapu
:Pacific/Truk
:Pacific/Wake
:Pacific/Wallis
:Pacific/Yap

-- DWF
dave@flaterco.com

https://flaterco.com/xtide/files.html#experts


Harmonics Notice

$Id: harmonics_boilerplate.txt 4391 2012-03-03 00:15:50Z flaterco $

Definitions and constants for XTide

NOTE: This file should not be used as-is to provide a constituent

set to harmgen because it contains multiple constituents with the

same frequency. A better constituent set is included in the harmgen

distribution (see the README).

********* NOT FOR NAVIGATION ********

*** DO NOT RELY ON THIS DATA FILE FOR DECISIONS THAT CAN RESULT IN ***

*** HARM TO ANYONE OR ANYTHING. ***

Highly trustworthy tide predictions cannot be achieved on a zero

budget. If you need guaranteed results, don't use these data!

Contact the tide authority for your region (NOAA in the U.S.).

This data file is distributed in the hope that it will be useful,

but WITHOUT ANY WARRANTY; without any warranty that its use will NOT

INFRINGE ANY RIGHTS, and without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

WHOEVER CHOOSES TO REDISTRIBUTE THESE DATA ASSUMES ALL LIABILITY

ASSOCIATED THEREWITH. NEITHER DAVID FLATER NOR ANYONE ELSE INVOLVED

SHALL BE LIABLE PERSONALLY OR OTHERWISE FOR ANY LOSSES THAT THE

REDISTRIBUTOR MIGHT SUFFER AS A CONSEQUENCE OF ANY CLAIMS, BOGUS OR

OTHERWISE, THAT ARE MADE TO THESE DATA.

--- Notes to contributors ---

After getting legal threats from the U.K. Hydrographic Office, I am

no longer willing to accept any data without an explicit statement

from the copyright owner or eminent authority either granting

permission for non-commercial use with XTide or explaining that such

permission is not required. The absence of a copyright notice is

not sufficient; however, a blanket permission for non-commercial use

is sufficient.

For more technical reasons, I am not prepared to accept data under

conditions that require me to track uses of the data, to limit the

uses of the data to a particular time period, or to verify that

every user has read the legalese. XTide has many different

interfaces by which users can obtain results, and such requirements

are impossible to implement in a reasonable and consistent fashion

across all interfaces. For a reasonable compromise, see what was

done for the POL data: a reference to legalese is included in the

location name field.

--- Copyright statements ---

United States: Data published by the U.S. government is by law

non-proprietary. Stations in the U.S., territories of the U.S.,

commonwealths associated with the U.S., and countries with a Compact

of Free Association with the U.S. have been included. A few other

stations available from the NOS web site have been dropped.

Notice available on the NOS web site at

http://tidesandcurrents.noaa.gov/disclaimers.html as of

2007-05-30:

The information on government servers are in the public domain,

unless specifically annotated otherwise, and may be used freely by

the public. Before using information obtained from this server,

special attention should be given to the date and time of the data

and products being displayed. This information shall not be

modified in content and then presented as official government

material.

The user assumes the entire risk related to its use of these

data. NOS is providing these data "as is," and NOS disclaims any

and all warranties, whether express or implied, including (without

limitation) any implied warranties of merchantability or fitness

for a particular purpose. In no event will NOS be liable to you or

to any third party for any direct, indirect, incidental,

consequential, special or exemplary damages or lost profit

resulting from any use or misuse of this data.

NOS requests that attribution be given whenever NOS material is

reproduced and re-disseminated. Pursuant to 17 U.S.C. 403, third

parties producing copyrighted (compilation) works consisting

predominantly of material created by Federal Government employees

are encouraged to provide notice with such work(s) identifying the

U.S. Government material incorporated and stating that such

material is not subject to copyright protection.

Canada: The harmonic constants used to perform tide predictions for

locations in Canada are derived from sea level data made available

by Marine Environmental Data Services, Fisheries and Oceans Canada,

for public, non-commercial use. The predictions are not the same as

those computed by the Canadian Hydrographic Service, which uses its

own sets of harmonic constants.

Copyright notice for the sea level data at

http://www.dfo-mpo.gc.ca/notices-avis-eng.htm (rev. 2009-07-17):

Non-Commercial Reproduction

Information on this site, other than government symbols, has been posted

with the intent that it be readily available for personal and public

non-commercial use and may be reproduced, in part or in whole and by any

means, without charge or further permission from Fisheries and Oceans

Canada, provided that:

* due diligence is exercised in ensuring the accuracy of the information

reproduced;

* Fisheries and Oceans Canada is identified as the source department; and

* the reproduction is not represented as an official version of the

information reproduced, nor as having been made in affiliation with, or

with the endorsement of, Fisheries and Oceans Canada.

Netherlands: The Netherlands data was contributed directly by Koos

Doekes of the Rijkswaterstaat RIKZ/ZDI, who grants permission by his

own authority:

Herewith I grant permission for non-commercial use

of all harmonic constants for the Netherlands by

users of Xtide or Xtide-based products.

This covers the use of the constants for Dutch

ports in the Xtide-database by designers

of web applications, and the use in commercial

tidal prediction software in which the constants

themselves are not stored - i.e. the user has

to copy them from the Xtide-database himself.

It does NOT cover the use in commercial software

in which the constants are incorporated, which is

considered commercial use of the constants here.

Any request for permission of use of Dutch constants

in software of this kind should be redirected to

RIKZ.

Germany: The Germany data was contributed directly by Wolfgang

Lange of the Bundesamt fuer Seeschifffahrt und Hydrographie (BSH),

who grants permission by his own authority:

As long as you make your software using these tidal data

freely available, I grant permission for non-commercial use

of the harmonic constants for the 12 reference stations at

the german North Sea coast on the same conditions and rules

layed down in the letter from Koos Doekes, RIKZ/ZDI,

concerning the Netherlands harmonic constituents.

UK: Received 2003-11-15 DWF. See also http://www.flaterco.com/pol.html.

Proudman Oceanographic Laboratory

Natural Environment Research Council

Bidston Observatory

Bidston Hill

Prenton

Merseyside

CH43 7RA

United Kingdom

David Flater

13320 Country Ridge Drive Tel +44 (0) 151 653 8633

Germantown, MD 20874 Fax +44 (0) 151 653 6269

United States of America www.pol.ac.uk

07 November 2003

Dear David,

This letter is to confirm that we are happy for you to download the

sea level data from the British Oceanographic Data Centre website and

use this in the generation of harmonic constants using the HarmGen

software. However there are a couple of things that we would politely

ask that you do.

1. Limit the number of harmonic constants you use in the software to

a maximum of 40 for any port. This should easily be enough to create

very accurate tidal predictions as for nearly all locations, any

harmonics left out (i.e. the 41st most significant constants onwards)

will have amplitudes of the order of a centimetre.

2. State that the data is derived from sea level data obtained from

the British Oceanographic Data Centre based at the Proudman

Oceanographic Laboratory, Liverpool.

3. Make it clear that the predictions however are not the same as

those computed by the Proudman Oceanographic Laboratory which uses its

own sets of harmonic constants.

4. Continue to make your software using the data freely available.

Please inform us if you intend to produce a software product that you

will be making a charge for.

I hope these conditions are acceptable to you and it will be good to

see the UK back on the map.

Yours sincerely,

Colin Bell

Head of Applications Group

Changelog

---------

2012-03-02 End of maintenance for non-free data

As a result of the combination of lack of time, commercialism, and abuses,

I have decided to officially end maintenance of the non-U.S. data, which

were subject to a non-commercial-use-only license. This will be the final

entry in the changelog in the monolithic, legacy formatted

harmonics_boilerplate.txt file. Future updates will be logged more legibly

in a new ChangeLog file bundled with the public domain data.

2011-12-30

Imported NOS data from snapshot 2011-12-11. Subordinate tide stations came

from the new web site; subordinate currents have not yet been migrated, so

the old process was used for them.

A small percentage of subordinate station links were broken at the time of

the snapshot, so a few stations will be down for the year. Most subordinate

tide stations that had complications attached to them disappeared in the

migration to the new web site and are probably gone for good. The new web

site does not [yet] serve up station notes, as far as I can tell.

The following four current reference stations stopped matching NOS

predictions and were dropped along with their subs:

Throgs Neck, 0.3 n.mi. NE of, Long Island Sound, New York Current (15d)

The Race, 0.6 n.mi. NW of Valiant Rock, New York Current (38d)

North Inian Pass, Cross Sound, Alaska Current

Unimak Pass (off Scotch Cap), Alaska Current

The meridian adjustment for College Pt was retained to make predictions agree

with 2012 sub station 8517276. Riverdale was fixed upstream (agrees with

2012 sub station 8518905). NOS predictions for Fortescue Creek and Texaco

Dock were unavailable for comparison, so they were again adjusted to agree

with their 2008 results.

The following two stations shifted *west* by 7 hours (i.e., a meridian of

+7 is needed to make the new data match the 2010 predictions):

9465234 Hagemeister Island (north end), Alaska

9465249 Estus Point, Hagemeister Strait, Alaska

NOAA predictions were unavailable for comparison; assumed OK.

2011-04-10

Imported up-to-date NOS harmonic constants for Wrangell Narrows Current

contributed by Mitch Cline via Dean Pentcheff. Reran import of subordinate

stations from December's web scrape to include all of the inside passage

currents that depend on Wrangell Narrows.

2010-12-30

Imported NOS data from snapshot 2010-12-19.

Compared data with 20081201 snapshot to find recently broken meridians.

Albany was fixed. Santa Cruz, Coyote Pt. Marina, and Moss Landing went

away. Adjusted meridians of the following to agree with 20081201 results:

College Pt, Ft. of 110th Street, Long Island, New York

Riverdale, Hudson River, New York

Fortescue Creek, New Jersey

Texaco Dock, Hackberry Bay, Louisiana

Fixed miscellaneous spelling errors and nits.

2010-05-29

Mark Randolph checked the rest of California and found one other station

that broke after December 2008 in the same manner as Santa Cruz: General

Fish Company Pier, Moss Landing, California. Fixed that and thanks again

to Mr. Randolph.

2010-05-22

Santa Cruz, Monterey Bay, California now has the same problem as Albany and

Coyote Point Marina (supposedly UTC data were LST). It broke between

December 2008 and December 2009. Thanks to Mark Randolph for reporting the

problem.

2009-12-27

Due to significant, uncorrectable differences with authoritative

predictions, the data for Germany were retired.

Imported NOS data from snapshot 2009-12-22.

Removed the current reference station Akutan Pass which no longer matches

published tables (maximum velocities have decreased).

Reapplied the meridian fixes for Albany and Coyote Point Marina. The

discrepancy for Albany versus the tide tables is now being reproduced by

the new NOAA tide predictor.

The LST harmonic constants for Johnston Atoll and Kwajalein changed

meridians this year. XTide does not use the LST constants, but there might

be some impact on agreement with NOAA predictions for the subordinate

stations that use those reference stations.

2008-12-28

Imported NOS data from snapshot 2008-12-01.

Reapplied the meridian fixes for Albany and Coyote Point Marina.

Corrected latitude of Monte Carlo Island, AK.

Fixed spelling of Monterey and Chapoquoit.

In light of the continued absence of harmonic constants for currents on

the NOS web site, I have reinstated 32 reference stations from CURCON00.US

that still match NOS' published 2009 predictions, together with applicable

subordinate stations from the 2008-12-01 web scrape. As always, there is

plenty of opportunity for improvement in the station names. States were

determined heuristically and some will be wrong.

The database now includes a state field that provides the 2-letter USPS

abbreviation for the state in which each tide station is located, when

applicable.

All TCD files and dumps are now being distributed in tarballs together

with the boilerplate.

2007-12-28

Imported NOS data from snapshot 2007-12-17.

Reapplied the meridian fixes for Albany and Coyote Point Marina.

Coordinates of I-526 bridge were fixed upstream.

A comparison of all reference stations versus the 2008 tide tables

published on the web revealed discrepancies for Anchorage, AK and Port

O'Connor, TX. The Anchorage discrepancies are small enough to be

explained by a data update; however, the Port O'Connor discrepancies are

major and are not helped by the meridian fix that worked for Albany and

Coyote Point Marina. Local observations are required to determine whether

the Port O'Connor predictions are any good at all. This is complicated by

the fact that it is a diurnal station with small tidal range, making

eyewitness confirmation that much more unreliable. Subordinate stations

depending on these reference stations will also fail to match the

published tables.

2007-11-22

To facilitate compliance with Linux distribution packaging policies

and to draw more attention to the acceptable use restriction on

non-U.S. data, the "free" and "nonfree" data are now being exported

to separate TCD files. At this time, all "free" data are public

domain and all "nonfree" data are merely restricted to

non-commercial use only.

Replaced the data set for Harwich, England with one calculated from

a longer time series. Proudman still does not yet publish

predictions for this location.

2007-03-18

Updated approximated MLLW datums with improved estimates.

Put IGNORE HEIGHTS in the legalese fields of the 14 subordinate

stations where NOS zeroed out the heights.

2007-02-22

Applied renamings as updated and improved by Walt Bilofsky (thanks

Walt).

2007-02-11

Interim release, without renamings.

Imported NOS data from snapshot 2007-02-07.

(9414449) Coyote Point Marina, San Francisco Bay, CA: corrected meridian.

(Data claimed UTC, was UTC-8)

(8518995) Albany, Hudson River, NY: corrected meridian.

(Data claimed UTC, was UTC-5)

I-526 bridge, Ashley River, South Carolina: fixed longitude.

Pascagoula, Mississippi Sound, Mississippi latitude was fixed upstream.

In progress: renamings.

Since there were two reference stations with incorrect meridians

(one that was reported last time and one that was just discovered),

it is reasonable to expect that there will be more.

2006-07-08

Coyote Point Marina, San Francisco Bay, California: corrected meridian.

Delaware City, Delaware River, Delweare: fixed typo in name.

Pascagoula, Mississippi Sound, Mississippi: fixed latitude.

I-526 bridge, Ashley River, South Carolina: fixed longitude.

2006-03-05

Installed renamings from AH for the 102 stations that lacked states.

2006-02-05

Refreshed U.S. data from NOS web site (snapshot 2006-01-04). AH has

dealt with new and modified station names to maintain the naming

convention installed 2005-11-27. Still to be fixed is a list of

stations that do not include their state in their name. Most or all

of those have been that way since November. They didn't stick out

much until an unrelated Harmbase query happened to group them

together.

An e-mail exchange with Todd Ehret of NOS CO-OPS this time led me to

believe that the UTC constants for the Alaskan reference stations

with weird time zones should be correct, so I have retained them. A

survey of affected subordinate stations shows that most should be

correct if their reference station is correct (they all use the same

one). Most doubtful are the six subordinate stations on

St. Lawrence Island. I do not even have reliable intelligence on

what the de facto time zone of St. Lawrence Island is. It was not

mentioned in the statute that defines U.S. time zones.

2005-11-27

Installed renamings from August Hahn to achieve something like the

naming convention previously followed in legacy data. These

renamings will be maintained through subsequent updates if the churn

is not too bad.

2005-09-05

Generated and installed harmonic constants for 49 Canadian stations

using up to 10 years of hourly data (the maximum permitted download)

from Marine Environmental Data Services (MEDS), Fisheries and Oceans

Canada.

MEDS publishes water level data for 962 stations. Of those, only 92

are currently active. Of those 92, 43 are non-tidal, being located

on or near the great lakes.

2005-06-05

Generated and installed fresh harmonic constants for U.K. stations

using all available data for the 19 year epoch from 1986 to 2004.

Quality assurance information is available at

ftp://ftp.flaterco.com/xtide/harmonics-dwf-2005-06-05-QA.txt

Station Harwich, England is new with only 8 months of data.

Authoritative predictions for this station are not yet available for

comparison.

2005-01-20

Deleted the following Alaskan reference stations, which were

rendered incorrect by technical difficulties confirmed by Todd Ehret

of NOS CO-OPS, and all dependent sub stations. They may return

corrected in future revisions.

- 9460150 Attu, Massacre Bay

- 9465261 Clarks Point, Nushagak Bay

- 9468132 St. Michael, Norton Sound

- 9497649 Prudhoe Bay

2

- 9497778 Cross Island

Also deleted the following station which is listed as superseded.

- 9497652 Prudhoe Bay, Dock

1

2004-12-10

Refreshed all NOS data from NOS web site.

2004-10-18

No data changes -- just resyncing and renaming all the different

editions of the database.

harmonics-dwf-2004-10-18-v2.tcd Built with libtcd 2.0

harmonics-dwf-2004-10-18-v1.tcd Built with libtcd 1.100

harmonics-dwf-2004-10-18.sql Postgres 7.4.2

harmonics-dwf-2004-10-18-dump txt/xml restored from -v2.tcd

harmonics-dwf-2004-10-18-compat txt/xml years 1970-2037 only

2004-10-08 DWF

Updated RIKZ/MII references to new name, RIKZ/ZDI.

2004-10-05 DWF

Rebuilt using libtcd 1.99, which corrects a problem where

constituents with zero phases were being dropped. The affected

reference stations are Delfzijl, Netherlands; The Battery, New York

Harbor, NY; and South Pass, LA.

2004-09-14 DWF

Imported subordinate stations available from the NOS web site as of

2004-09-09. Compare against

http://co-ops.nos.noaa.gov/tide_pred.html. Some stations will

disagree moderately because the reference stations were updated and

don't match the published tables.

The smattering of sub stations in non-U.S. territory was suppressed.

There are time zone problems in Alaska. The LST used by the NOS for

stations in Alaska does not always match the local statutory time

zone (which I have followed). For reference stations, the problem

was detectable and correctable because the constants were available

calibrated with UTC as well as LST. But for the sub stations, it is

impossible to tell whether a disagreement with NOS predictions

results from a disagreement about time zone, incorrect calibration,

or both.

A few names suffixed by (A) and (B) reflect sub stations on the NOS

web site with the same names and close coordinates, where it is far

from obvious why there are two of them. Other name clashes were

resolved by disambiguation.

(Nit) Corrected months_on_station for German ref stations from 13 to

12. (It's a time zone / rounding issue, on list to be fixed.)

2004-09-07c DWF

Put the following three stations on Eastern time (they were calibrated

to Central time on the NOS web site):

Johns Island, Chassahowitzka Bay, FL

Chassahowitzka River, FL

Crystal River, Kings Bay, FL

2004-09-07b DWF

Corrected heuristic for Alaskan time zones. A few stations in the

Aleutians were affected.

2004-09-07 DWF

Added notes for stations in Alaska where the LST used by NOS does not

match the apparent statutory time zone. Presently these notes just

get attached to the comments field in the TCD file, but the next major

revision to the TCD format should enable XTide to display them more

prominently.

2004-09-01 DWF

Most reference stations available from the NOS web site as of

2004-08-26 have been imported. Compare against

http://co-ops.nos.noaa.gov/tide_pred.html.

MLLW benchmarks were not available for all stations. For stations

where a MLLW datum was not available, the datum has been set to LAT.

I know there are typos in the location names.

Currents are not available at this time. According to Mr. Ehret, they

will become available when the new CO-OPS currents database is

complete.

The following stations, which are located in jurisdictions that are

neither territories of the U.S., nor commonwealths associated with the

U.S., nor countries with a Compact of Free Association with the U.S.,

have been dropped. Their data are distributed without legalese from

the NOS web site; however, that does not necessarily mean that anyone

other than the NOS has permission from the respective governments to

use or redistribute the data. This may seem paranoid, but the

situation with the U.K. data that were pulled in 2001 was very

similar.

Apia, Samoa

Bermuda Esso Pier, St. Georges Island, Bermuda

Fare Ute Point, Papeete Harbor, French Polynesia

La Unión, El Salvador

Madero, Tampico Harbor, Tamaulipas, Mexico

Puerto Corinto, Nicaragua

Puerto Cortés, Honduras

Puerto Quetzal (San Jose), Guatemala

Settlement Point, Grand Bahama I., Bahamas

Suva Harbor, Suva, Fiji

2004-08-19 DWF

This is an interim release as I am starting over from scratch using

Harmbase2. All legacy data have been dumped.

All U.S. data are temporarily down; the 2004-08-09 version of this

file remains usable for those. Mr. Ehret has indicated that there

would be fees involved in obtaining harmonic constants and offsets

in the format previously received, so I am abandoning all that and

gearing up to scrape data off of the web. According to Mr. Ehret,

the set of locations on the web site is a superset of those used in

published prediction tables. The discrepancies that occur are

because the harmonic constants on the web are updated continuously

while the harmonic constants used for the published tables are fixed

in advance. Thus there seems little to be lost by replacing all of

the legacy data with a snapshot of the web data.

Data presently included:

Netherlands reference stations computed from hourly levels 1999

through 2002, as received from Koos Doekes on 2004-02-03. Compare

against http://www.getij.nl/engels/.

German reference stations computed using Harmgen from year 2001

observations sent by Wolfgang Lange on 2004-08-19. The datums are

adjusted to LAT. Compare against

http://www.bsh.de/en/Marine%20data/Forecasts/Tides/index.jsp. (The

web site is still using the MLWS datum, so the heights will disagree

strongly until the web site is updated. However, even adjusting for

that, the agreement is not as good as could be hoped. The BSH

predictions are made using a non-harmonic method, so some

discrepancies are inevitable.)

German subordinate stations as sent by Wolfgang Lange on 2004-08-10.

U.K. reference stations computed using Harmgen from at least four

years of observations ending 2002-12-31, as downloaded from the BODC

web site 2003-11. Compare against http://www.pol.ac.uk/ntslf/tides/.

2004-08-09 DWF

harmonics-dwf is a new database that emphasizes responsiveness to

updates and traceability to authoritative sources instead of maximum

coverage of locations and historical predictions. All data known to

be old and expired and all data for which no source of updates

exists have been purged. This will orphan many users who have been

getting good results from old data. For these, please continue to

use RMK's database.

harmonics-dwf now contains:

- U.S. reference stations provided by Todd Ehret of NOAA circa

2004-02-04.

- Netherlands reference stations provided by Koos Doekes of the

Rijkswaterstaat RIKZ/ZDI (then RIKZ/MII) on 2004-02-03.

- U.K. reference stations derived by Harmgen from BODC data,

2003-11.

- The most recent data for other U.S. reference stations that

were in RMK data rev. 2004-04-16 23:30 but not included in

the distribution from Todd Ehret.

All sub stations are gone temporarily while I update my software to

import the sub station data sent by Todd Ehret in February. I will

also be contacting Mr. Ehret to see if I can obtain a complete dump

of all stations in current use so that I can build a legacy-free

database.


Design notes

Principles

As originally codified:

  • Portability
    • The scope is all "reasonably modern" flavors of Unix, X11, and C++.
    • Limit language features to those that reliably compile.
    • Respect the holy mantra "./configure; make; make install".
    • Allow trivial workarounds for platform- and distribution-specific bugs or special requirements.
    • Disallow nontrivial workarounds and those that conflict with correct operation on non-broken platforms.
  • Availability
    • Limit hard dependencies on external tools and libraries to those that are typically pre-installed.
  • Usability
    • Maximize orthogonality of settings and switches.
    • Support both interactive and non-interactive use.
    • Command-line switches should be no more than two characters long.
  • Maintainability
    • Accept no bogus patches.
    • Maximize orthogonality of modules.
  • Stability
    • Accept no bogus patches.
    • Use no unstable tools or libraries.
    • If it ain't broke, don't fix it.
    • If it damages usability or maintainability, it's considered broke.
    • Do not merely deprecate that which deserves to be deleted.

As it happened:

  • Portability
    • Within the original scope, no Unix but Linux and no compiler but GCC gets much testing anymore.
    • Scope creep: the workarounds that are included to allow building the command-line client with Visual Studio are ridiculous.
    • Building libxtide for Android required few source code changes but plenty of autoconf tricks.
  • Usability
    • The font settings are context-sensitive.
  • Maintainability
    • I have accepted some bogus patches and made them work, but no more.
    • Font and character set handling has become totally non-orthogonal because every context is different.
  • Stability
    • libXaw3dXft has been unstable (every update breaks the XTide build, but there are no version defines to check).
    • The –ns and –nf switches are deprecated but deserve to be deleted.

Harmonics files

XTide has a long history of harmonics file woes and has been through four different file formats trying to solve them.

 | Readable | Extensible | Efficient | Available
TXT | X |  |  | X
XML |  | X |  | X
SQL |  | X | X |
TCD1 |  |  | X | X
TCD2 |  | X | X | X

XTide 1 used a nice, human-readable text format (harmonics.txt) but it was neither efficient nor extensible. New fields that were really, really necessary got wedged in as "hot comments," initiating a long downhill slide into architectural chaos.

Unwisely, XTide 2 perpetuated the harmonics.txt format but added a new, extensible XML format for subordinate stations only (offsets.xml). It was anticipated that one of two things would eventually happen: either a reasonably functional and stable SQL database would become standard issue with the average Unix, obviating the need to avoid that external dependency, or harmonics.txt would go away and all stations would be done in extensible XML. Neither one happened. Migration to XML was put off repeatedly because it would exacerbate the performance bottleneck.

Everybody suffered with the lousy performance until Jan Depner proposed to implement a binary format (TCD). TCD1 fixed the performance problem but the extensibility problem persisted. New fields could be added with just minor changes to libtcd, but then you needed to recompile the world. Old versions of XTide couldn't read new harmonics files after fields were added. This had a major chilling effect on all development that would have required new fields.

TCD2 (a major, incompatible revision) emptied the queue of incompatible changes but also added a field whose content is extension fields encoded as text. Adding fields this way is not as efficient as adding new binary fields, but it avoids the need to make an incompatible revision over small stuff. The option to add new binary fields and bump the major rev remains open should that become necessary.

Unfortunately, as I forget who once observed, "The worst enemy of the great is the barely good enough." Among the downstream user community, the obsolete and hopeless .txt and .xml formats refuse to die.

Known problems

Consensus is that the XTide source code does a miserable job of separating the user interfaces from the reusable tide-prediction logic. As of XTide 2.14 the common files have at least been bundled into a library that can be built upon without making too much of a mess. However, the XML parser still protrudes into the global namespace, conflicting with any other lex/yacc type parser that the app might want to link with.

Lots of serious design problems were fixed in refactorings beginning with version 2.7 (early 2004) and continuing through version 2.9. Remaining minor problems:

  1. The interface with X11 is still weird, especially bootstrapping.
  2. The analog tide clock icon caused more problems (with buggy window managers) than it was worth.
  3. URLs assigned to prediction pages by the web server should probably be based on the harmonics file name and the location name rather than a transient "row ID."
  4. Constituent inference was patched in via libtcd and maybe could have been integrated better. In theory, you might want to control it on a station-by-station basis like preferred units, and it probably should not require a station reload to turn it on or off.
  5. Graph and calendar modes are implemented by transient classes. These are not proper objects, but they are too complicated to be implemented with methods alone.
  6. libtcd doesn't let you know whether you are looking at a tide station or a current station until after you load it.
  7. The mechanism that XTide 2.13 and later use to get client side fonts for use in tide graphs is an abomination.
  8. Calendar mode needs an "extended subset" of the settings that every other mode uses.
  9. Application-specific error messages don't belong in libxtide.
  10. Graph mode is a bottomless source of requests for more settings to customize it.

C++ feature footprint

At the time XTide 2 was developed, the fancier features of C++ such as the Standard Template Library (STL) and exceptions did not work in a portable fashion among the commonly available compilers, so their use was avoided. Similarly, Qt and other free alternatives to Motif were not widely available, so Athena Widgets were used. The resulting interface may seem primitive by today's standards, but it still works.

By the time of the 2.7 refactorings, the STL appeared to be stable and widely available, so standard templates were introduced where appropriate to simplify new code. Old code was not STLified until the Great Cleanup of 2006 (XTide 2.9).

The long long int data type was introduced in XTide 2.6 as part of the changes to handle dates before 1970 and after 2037. Nobody complained.

Streams were expunged from XTide 2.6 after compilers started deprecating XTide's use of them. In XTide, C++ streams did not add value versus plain old C I/O, but this is not the case for every application.

The bool data type was introduced in XTide 2.9. C++11 extended initializer lists were used in new code in XTide 2.13, but made optional in XTide 2.13.1 because of continued non-support in Visual Studio 2012.

Exceptions are still not used, but should be. The bounds-checking operation[] of SafeArray should be replaced with the now-standard at() function.

Coding conventions

A uniform coding convention was imposed in XTide 2.9 (year 2006). See the file CodingConventions.txt included in the distribution tarball. As of 2012, particularly with the issuance of C++11, it has become problematically obsolete in some areas.

Paths not taken

  • There ought to be a way to specify relative dates and times in the –b and –e fields. Need an applicable standard; ISO 8601 doesn't support it.
  • Generate maps for xttpd navigation and general illustration, include in LaTeX form.
  • Several people have asked for a line in text listings for the current time, like "2001-03-19 11:50 AM PST 0.10 feet Falling," but it's not clear what the settings and behaviors should be to handle the "now" event consistently across all modes. Graphs and clocks have their own ways of showing the "now," and it would be inappropriate to include "now" in a calendar.
  • Most tide prediction software generates node factors and equilibrium arguments monthly or at least does it for the middle of your prediction interval, but the legacy of SP98 is to do it yearly.
  • Doodson style tide prediction as used by Godin/Foreman's IOS package:
    1. No new Doodson data appear to be forthcoming.
    2. Most Doodson constituents are approximated fairly well by Congen. The ones that aren't approximated well are those that are drastically affected by latitude. To support latitude-dependent constituents, node factors and equilibrium arguments would have to be generated internally to XTide, which would be a significant architectural change. [Casement opined that the latitude-dependent method is bogus anyway because tides are generated someplace in mid-ocean with a different latitude.]
    3. If you want IOS, then use IOS.


Differences from XTide 1

[As if anybody remembers XTide 1. This section is now obsolete.]

XTide 2 is a complete redesign of XTide 1. There are too many subtle improvements to list them all, but here are the not so subtle ones:

  • New interactive user interface for X windows client
  • Integrated web server now provided in distribution
  • Simpler, better command line interface
  • Handles multiple harmonics files transparently
  • Subordinate stations are now stored in an external database and are expanded to handle all known styles of offsets
  • Hydraulic currents are fixed
  • Removed useless options and modes
  • Added sun and moon information (by popular demand...)
  • Fast, efficient binary format for harmonics data

These are the non-obvious things you must know in order to migrate:

  1. The environment variable HFILE is no longer used to specify the harmonics file; instead, HFILE_PATH is used:
    export HFILE_PATH=/usr/local/share/xtide/harmonics.tcd
    If HFILE_PATH is not set, XTide looks for the file "harmonics.tcd" in the default directory.
  2. XTide now has its own built-in icon. Remove any icon settings that you made in your window manager init files. [Since the icon protocol that XTide 2 uses is no longer supported by newer window managers, that advice can be disregarded.]
  3. You may no longer use anonymous units in harmonics files. The units must be one of the recognized alternatives. These are: feet, meters, knots, knots^2 (for hydraulic currents). If you are still using an ancient harmonics file that contains no units or "bogo-knots," then shame on you. It's high time that you upgraded.


Bibliography

Canonical sources on the NOS tide prediction methodology (including a mathematical explanation from first principles in SP98):

Manual of Harmonic Analysis and Prediction of Tides. Special Publication No. 98, Revised (1940) Edition (reprinted 1958 with corrections; reprinted again 1994). United States Government Printing Office, 1994. Downloaded from NOAA Central Library via NOAA's Historical Map & Chart Collection, 2015-04-27.

Computer Applications to Tides in the National Ocean Survey. Supplement to Manual of Harmonic Analysis and Prediction of Tides (Special Publication No. 98). National Ocean Service, National Oceanic and Atmospheric Administration, U.S. Department of Commerce, January 1982. Downloaded from NOS, 2016-12-18.

Miscellaneous publications available from https://flaterco.com/xtide/files.html#pubs:

Tide and Current Glossary. National Ocean Service, January 2000. Downloaded from NOS, 2003-12-19.

Tidal Datums and their Applications. NOAA Special Publication NOS CO-OPS 1, June 2000. Downloaded from NOS, 2004-08-27.

Nathaniel Bowditch, LL.D. The American Practical Navigator: An Epitome of Navigation. NIMA Pub. No. 9, Bicentennial Edition, 2002. Downloaded from NGA, 2004-09-28. 42 MB. Chapter 9 is a tutorial on tides and currents.

My sources for X-windows programming reference:

Kimball, Paul E. The X Toolkit Cookbook. Prentice Hall P T R, New Jersey, 1995.

Nye, Adrian. Xlib Programming Manual. O'Reilly & Associates, Inc., Volume 1, Third Edition, July 1993.

A catalog of information on the ISO 8601 standard date and time notation can be found at http://dmoz.org/Science/Reference/Standards/Individual_Standards/ISO_8601/.

iCalendar format and usage is according to RFC 2445 and RFC 2446, with some hints taken from RFC 2447 (November 1998).

Harmgen uses ordinary least squares for harmonic analysis of tides. An improved method that is more robust to outliers in the data is described in

Keith E. Leffler and David A. Jay, "Enhancing tidal harmonic analysis: Robust (hybrid L1∕L2) solutions," Continental Shelf Research, 2008. Available at http://web.cecs.pdx.edu/~jaylab/group/leffler/publications/Leffler_Jay_2009.pdf.

An article about a model-based approach to tide prediction, which is completely different from what XTide does, is

Derek Goring, "Computer Models Define Tide Variability," The Industrial Physicist, v. 7, n. 5, October/November 2001, pp. 14-17.

Michael Foreman's publications are a good read if you are interested in the Doodson approach to tide prediction.

Foreman, M.G.G., 1977. Manual for Tidal Heights Analysis and Prediction. Pacific Marine Science Report 77-10, Institute of Ocean Sciences, Patricia Bay, Sidney, B.C., 58 pp. (2004 revision).

Foreman, M.G.G., 1978. Manual for Tidal Currents Analysis and Predition. Pacific Marine Science Report 78-6, Institute of Ocean Sciences, Patricia Bay, Sidney, B.C., 57 pp. (2004 revision).

Foreman, M.G.G., and R.F. Henry, 1979. Tidal Analysis Based on High and Low Water Observations. Pacific Marine Science Report 79-15, Institute of Ocean Sciences, Patricia Bay, Sidney, B.C., 36 pp. (2004 revision).

Miscellaneous publications mentioned by Hugh Casement that I haven't read:

On the response method of tide prediction, which is completely different and allegedly better than what XTide does: Munk, Walter H.; Cartwright, David E.: Tidal spectroscopy and prediction. Philosophical Transactions of the Royal Society, A 259 (1966).

An interesting-sounding publication that Hugh Casement hasn't read either: Horn, Walter: Some recent approaches to tidal problems (Centre Belge d'Océans, Brussels, year unknown).

Horn, Walter: Tafeln der Astronomischen Argumente V0 und der Korrektionen j, v (Deutsches Hydrographisches Institut, Hamburg, 1967).

Doodson, in Proceedings of the Royal Society A.100 (London, 1921).

Cartwright and Tayler, in Geophysical Journal of the Royal Astronomical Society 23 (1971).

Jean Meeus, Astronomical Algorithms, Willmann-Bell.


Credits

Very few of the ideas and very little of the know-how implemented in XTide originated with me. I just took the ideas and knowledge of others and turned them into software.

Underneath all the fluff, the central tide prediction algorithm implemented by XTide is by the book, specifically U.S. Coast and Geodetic Survey Special Publication 98 by Paul Schureman. It was originally published in 1924. Fans of retrocomputing might be interested to know that tide graphs of the style produced by XTide were once produced by machines that implemented the algorithm in hardware, in the hardest sense of the word (see Figure 1, or read all about them at http://tidesandcurrents.noaa.gov/predmach.html).

Figure 1. Tide-Predicting Machine No. 2

Since we do it on a computer now, we had to make it a lot more complicated by handling subordinate stations, time zones, umpteen different output modes and formats, etc. For those complications, I thank my colleagues ;-)

XTide 1 began as nothing but a tide clock with no other modes and very few details. It grew like a weed with code and ideas being contributed by a small but industrious group of people. Actually, "weed-like" is a very accurate description of how it grew. Clone-and-hack was all the discipline we had. Before long, the command line was cluttered with poorly factored, specialized switches, and you couldn't change anything without changing the same thing in nine places. In short, the weeds took over the lawn.

XTide 2 was the result of a unilateral crusade to impose a coherent architecture so that the thing would become maintainable again. Since that rewrite, outside contributions have been less frequent, but no less important.

In terms of actual source code in XTide 2, the people who contributed big chunks were:

Jan C. Depner was prolific in delivering the flat map, the World Vector Shoreline code, libtcd, tcd-utils, and inferred constituents. Most of his work was paid for by the U.S. Naval Oceanographic Office, making them the first organizational sponsor of XTide development. Thanks!

John Thorstensen allowed me to reuse code from his skycal distribution (ftp://iraf.noao.edu/contrib/skycal.tar.Z) to get the sun and moon calculations.

Geoffrey T. Dairiki's fast root-finding code survives in XTide 2 with only a C++ veneer.

Jack Greenbaum contributed the original patch to add SVG support.

For the "black magic" of Congen and Harmgen, I had some mentors:

The late Edward P. Wallner was a mentor for several years. With his assistance, I was able to fill in enough of the gaps in my understanding of SP 98 to write the Congen program. Along with Hugh Casement, he helped to sort out differences in the tidal constituents used in various countries. Ed's own tide-predicting shareware (now freeware) is archived for posterity at https://flaterco.com/files/wallner/.

Charles Read and Björn Brill provided the tutoring required for me to write the Harmgen program.

The support for Doodson style constituents in Congen was accomplished by reading and learning from Michael Foreman's publications and software by G. Godin and/or Foreman, which at the time were freely available on the web.

Other contributions in no particular order:

Thanks to Walt Bilofsky, August Hahn and Bob Kenney for miscellaneous help with data maintenance.

Thanks to everyone mentioned in the changelog for various patches, enhancements, and bug fixes.

Thanks to those who packaged XTide for Linux distributions and built contrib packages.

Thanks to those who ported XTide to other operating systems.

Thanks to Alan Eugene Davis for especially diligent beta testing.

The XTide 1 contributions are summarized below. I apologize if anyone has been forgotten.

People who submitted big chunks of code: Jeff Dairiki, Jack Greenbaum, Dean Pentcheff, and Jef Poskanzer.

People who submitted bug fixes, portability patches, and the like: Simon Burge, Jeff Dairiki, Andrew Davidson, Geoff Kuenning, Rob Miracle, Stan Uno, and Eric Rosen.

People who ported XTide to other platforms: Walt Bilofsky, Dale DePriest, Mikhail Fridberg, Mike Hopper, Paul C. Roberts and "Alex" somebody.

People who suggested features and/or beta tested: Bruce Bowler, Alan Eugene Davis, Dale DePriest, Jack Greenbaum, Phil Hughes, Bob Kenney, Dean Pentcheff, Jef Poskanzer, Graeme Rae, Greg Seidman, Jeff Small, Tom Varga, and Georg Vollmers.

People who supplied data: Tom Brown, Edward J. Corbett, Karl Hahn, Scott Hemphill, Jean-Pierre Lapointe, Dean Pentcheff, Frank Smith, Toru Suzuki, Ed Wallner, and "George" somebody.

The original interpolation algorithm for subordinate stations with unequal offsets was contributed by Jean-Pierre Lapointe.

Jeff Small wrote the original XTide man page.

Finally, thanks to all the other testers and folks who complain when something breaks—you know who you are :-)


Change log

XTide 2.15.2 (libxtide.so.1.0.2) (2019-02-24)

(Bug) Escape ampersands and < characters in text strings in SVG images. Bug report credit: Stephen Woodbridge.

(Bug) Added AM_DISTCHECK_CONFIGURE_FLAGS to Makefile.am to enable make distcheck to succeed when out-of-path includes and libs are necessary to build.

(Code rot) Adapted to new toolchain producing xml_y.hh where it used to have xml_y.h.

(Code rot) Updated URLs for generation of text files from HTML.

XTide 2.15.1 (libxtide.so.1.0.1) (2016-02-22)

(Regression) Fixed "bind: Invalid argument" failure of xttpd on FreeBSD and OS X (El Capitan). Linux and Android are not affected. Bug report credit: Manfred Antar.

XTide 2.15 (libxtide.so.1.0.0) (2016-01-25)

This release is all about catching up with external changes, with significant additions occurring only to xttpd. Users of the 2.14 versions of xtide, tide, and libxtide won't notice a functional difference, but some build script breakage has been fixed.

Added systemd support to xttpd (with thanks to Mamoru Tasaka):

  • When configured with --enable-systemd, xttpd links with libsystemd and runs as a "simple" socket-activated service. This removes the need for xttpd to be launched with root privileges but requires additional config files to be installed.
  • Added scripts/systemd containing xttpd.socket and xttpd.service.
  • Harmonizing changes to barf messages in libxtide.

Other xttpd improvements:

  • Made work with IPv6.
  • Invoke daemon() if not using systemd.
  • Log empty requests as such instead of "Bad client command" with no details.
  • Improved guessing of hostname when webmaster address is not specified.
  • Added -DXTTPD_NO_DAEMON option for debugging/testing and as a kludge for Android.

For Xaw3dXft:

  • Fixed freetype2 detection (was failing on Slackware 14.1).
  • Updated xxX.cc to the 1.6.2d API.
  • Updated configure to detect 1.6.2d and not any earlier version. Note: Every update tends to break the build, but there are no version defines to use defensively.

Updated Android, VS, and DOS build scripts for Android NDK r10e, Visual Studio Community 2015, and DJGPP 2.05 respectively, and the current versions of everything.

Obscure changes to build scripts for compatibility with new versions of automake/autoconf:

  • Added AUTOMAKE_OPTIONS = subdir-objects to Makefile.am.
  • Fixed consequential damage to XML parser recipes. Note: Newer autotools produce scripts such that regeneration of the XML parser will fail. You get xml_y.hh instead of xml_y.h. For now, stick with the working build scripts generated by older autotools.
  • Added m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) to configure.ac.

XTide 2.14 (libxtide.so.0.0.0) (2014-11-02)

Moved all "common" files into a separate library and namespace, libxtide. If libdstr is not provided the Dstr class gets included in libxtide.

Enabled building libxtide, tide, and xttpd for Android:

  • Fixed configure.ac nit that blocked cross-compiling.
  • Added configure option --enable-lm_hard.
  • Added workaround for Android/Bionic quirk of failing on zoneinfo paths introduced by a colon character. This fixes the time zones problem that affected MX Tides.
  • Added example script for cross-compiling libpng, libtcd, libxtide, tide, and xttpd for Android on x86 or x86_64 Linux in scripts/Android.

Other portability and code rot:

  • Added new build script for Visual Studio. The Cygwin dependency is removed at the cost of using a pre-generated configuration. Zlib and libpng are now built automatically with no mucking about in the Visual Studio IDE.
  • Updated Makefile.dj2 for DJGPP 2.04 and to build libxtide.
  • Changed GCC minimum version test to ignore Clang, which fraudulently identifies itself as an old GCC. Bug report credit: Ryan Schmidt.
  • Changed GCC minimum version failure into a big ugly warning. Since initializer lists have become optional, some pre-4.4 versions work again.
  • Replaced a preprocessor test for Visual Studio with a more general configure-time check for whether std::vector has an initializer_list constructor. This fixes the SafeVector build error on OS X Mountain Lion. Mavericks was never afflicted. Bug report credit: Dan Hinckley.

New settings:

  • XTide*caldayfmt (–cf) controls the format string used to print days in calendars.
  • XTide*linebreak (–lb) controls whether or not calendar mode inserts a line break before prediction values. This reduces truncation in text format and tweaks line wrapping in HTML and LaTeX formats.
  • XTide*omitunits (–ou) prints numbers with no ft/m/kt and adds a header line stating the units and datum (where possible).
  • XTide*pagebreak (–pb) controls whether or not calendar mode inserts a page break and repeats the station header for each month in text, HTML, and LaTeX formats. Text uses form feeds and HTML uses a page-break-before style.

New, experimental configurable --enable-moon-age replaces the moon phase column of calendar mode with moon age. This number wants to be replaced by graphics showing the moon as it would appear (approximately) on each day of the lunar month as originally suggested by Kelly Bellis, but it's not easy to implement that consistently across all formats. FWIW, Unicode 1F311 through 1F318 provide characters for 8 phases of the moon that could be used in UTF-8 text modes.

(Tweak) Centered calendar cell contents in HTML and text formats as they already were in LaTeX format.

(Note) In most modes the approximately zero prediction values associated with slack water events are output, but they are omitted in calendar mode. Noted but not changed.

Thanks to Kelly Bellis for suggestions to improve calendar mode.

XTide 2.13.2 (2013-07-21)

(Bug) Fixed that a UTF-8 locale didn't make any difference to text form graph and clock mode output.

(Portability) For DOS:

  • Updated bundled Dstr to version 1.0.
  • Added CP437 as a possible codeset value (requires Dstr 1.0).
  • Customized BROKEN_ZONEINFO error message for DJGPP.
  • If nl_langinfo isn't available, the hardcoded value for codeset can be selected at compile time by defining CODESET.
  • Added DJGPP makefile and suggested settings in scripts/DOS.

(Feature) Made the default prediction interval configurable (new setting –pi replaces Global::defaultPredictInterval).

XTide 2.13.1 (2013-07-10)

(Code rot) libXaw3dXft 1.6.2b changed the name of the library and include path again.

(Code rot) Disabled the ancient and obsolete zoneinfo compatibility hack for everything except Visual Studio because it masked time zone breakage in an Android port.

(Portability) Removed requirement for the C++ compiler to support C++11 extended initializer lists and got the Visual Studio build working again.

(Removed limitation) Incorporated patch from James Ashton to replace the Skycal etcorr function, which was limiting moonrise/moonset predictions to years 1900 through 2099.

Nit fixes:

  • Build scripts: only the interactive client needs to link with libgps. Tested with gpsd 3.9.
  • Per Kelly Bellis suggestion to expose version number through GUI: added "About XTide" to options menu; added version string at the top of the disclaimer text.
  • Added missing entry for Control Panel in help for options menus.
  • Documented that datefmt setting is ignored in calendar mode.

XTide 2.13 (2012-06-03)

(Misfeature) Mostly eliminated the need to set the resource XTide*beNiceToColormap: False to avoid ugly borders with Xaw3d and Xaw3dXft. Added documented bug for the remaining case, which afflicts xxHorizDialog via libXaw3d's asciiTextWidgetClass and seems unfixable.

(Nit) Deleted a superfluous configuration change for libXaw3dXft.

(Nit) Fixed new (GCC 4.7.0) warnings in Date.cc, xxRoot.cc, and xxX.cc.

XTide 2.13 RC3 (2012-03-04)

(Code rot) libXaw3dXft took a hard left turn and jumped versions from 1.3.3 to 1.6.2. RC3 will correctly detect and use libXaw3dXft 1.6.2, but is no longer compatible with 1.3.3. A tweak that fixes the problem with long menus in the Set Time dialog is enabled.

Caution: If using Xaw3d or Xaw3dXft, borders will be ugly unless you set the resource XTide*beNiceToColormap: False.

(Compatibility) Added a workaround so that GCC 4.4 can build the complicated extended initializer list in Global.cc.

(Tweak) If building with GCC 4.6 or above, use #pragma GCC diagnostic ... to quash nuisance warnings.

XTide 2.13 RC2 (2012-02-25)

(Nit) Configure: Add CPPFLAGS for FreeType only when actually needed.

(Cleanup) Removed unused field from ClientSide::Glyph.

(Optimization) When creating ClientSide::Font, null out and skip characters 0–31 and 128–159.

XTide 2.13 RC1 (2012-02-21)

This release candidate of XTide requires compiler support for C++11 extended initializer lists. GCC has supported them since version 4.4. Visual C++ 2010 Express Edition doesn't have them, so the Visual C++ build is on ice until something changes.

(Feature) For Athena Widgets, configure will now look for Xaw3dXft (≥ 1.3.3), Xaw3d, or Xaw, in that order. Plain Xaw can be forced using ––disable-3d. Thanks to Jean-Pierre Demailly for patches to make XTide work with Xaw3dXft (and vice-versa).

  • Xaw3d is a fork from an old version of Athena Widgets that offers improved scrollbars and a different look for buttons. Its last release was version 1.5E in 2003. Some issues that were subsequently fixed in Athena Widgets, such as long menus running off the screen, were fixed differently in Xaw3d. (This affects the Set Time dialog, where the list of years to choose from can be quite long.)
  • Xaw3dXft is a fork from Xaw3d 1.5E that uses FreeType fonts. The primary site is http://sourceforge.net/projects/sf-xpaint/files/libxaw3dxft/.

(Feature) GUI improvements:

  • Made location list and disclaimer windows resizable.
  • Fixed layout in location choosers.
  • Added keyboard handler to scrollable viewports.
  • Added –mf setting to select monospace font (interactive client only).*
  • Added –gf setting to select graph/clock font (interactive client only).*
  • Fixed text alignment in graphs again.
  • Changed embedded graph font to LiberationSans.
  • Set a maximum initial height on the control panel.

* Important usage note: If XTide is built with Xaw3dXft, font names given to XTide must be in fontconfig format (e.g., "Helvetica-10"), rather than the traditional XLFD (e.g., "-*-helvetica-*-r-*-*-10-*-*-*-*-*-*-*"). Also, Xaw3dXft does not return errors if there are problems with a font name; it just loads a default font instead.

(Code rot) Added thousands of unholy casts to make the "warning: deprecated conversion from string constant to 'char*'" nagging go away for all the places where I have to call library functions that don't use const. Between that nagging and the new nagging about auto_ptr, the deprecation was getting thick in here.

(Compatibility) Fixed problem with graph mode no longer working right on a VT100. If TERM is set to vt100 or vt102 and text form is requested, the Special Graphics set will be used to get the middle dot and degree sign characters. However, non-ASCII characters in location names and other data received from the TCD file will still do something weird. Bug report credit: John Andrews.

(Feature) If TERM is set to vt100 or vt102 and text form is requested, depth lines in graphs will be aligned better using characters from the Special Graphics set. (I don't have a VT100, but it looks right in xterm's emulation.)

(Misfeature) Made HTML form of about mode less ugly.

(Bug) Corrected inconsistent quantization of coordinates (inconsistent rounding of half-pixels) in the Graph hierarchy.

(Compatibility) Added a cast to work around an ambiguous overload of waitpid (used in xttpd.cc) that appeared with GCC 4.5.3 and Cygwin. (Did not occur with GCC 4.6.2 under Linux.)

(Code rot) Updated backward-compatible time zone mapping for Samoa. The entire hopeless workaround for obsolete zoneinfo should be killed with fire, but it is still invoked when tide is built with Visual C++.

XTide 2.12.1 (2011-11-27)

(Bug) Fixed missing encoding (character set) specification in SVG, which caused browser SVG rendering to fail when the station name contained interesting characters. Bug report credit: Keith N. Smith.

(Portability) Updates to support building tide.exe using Visual C++ 2010 Express Edition:

  • Removed a use of snprintf.
  • Worked around the absence of a scanf format compatible with uint8_t. The previous default of guessing "hhx" whenever SCNx8 was not properly defined led to memory corruption, as Visual C++ would treat the target variable as something larger than 1 byte.
  • Updated build procedure in documentation.

(Nit) Updated CONFIGURE-HELP from autoconf's INSTALL.

XTide 2.12 (2011-11-03)

(Bug) Removed incorrect SVGGraph.cc dependency on X11 (thanks Jeff Dairiki).

XTide 2.12 RC1 (2011-08-28)

(Feature) Added support for the SVG format. Thanks to Jack Greenbaum.

  • Command line client supports –fv.
  • Interactive client supports choice of format when saving clocks and graphs.
  • xttpd uses JavaScript to decide between SVG via the embed tag or PNG via the img tag.

(Code rot) The nofill (–nf) setting was deprecated in favor of graphstyle (–gs), and the anti-alias (–aa) setting went away.

(Feature) Added a fancier style of graph (generalized from Jack Greenbaum's SVG code, example possibly embedded below) as graphstyle s (semitransparent). Set opacity with –to; set line width with –lw. Note that semitransparent style makes no sense in formats that don't support opacity (text and PseudoColor X-windows).

(Speedup) On TrueColor displays, graphs and clocks are now drawn by constructing an RGBGraph and converting it to a Pixmap. xxPixmapGraph (the Graph implementation that uses X11's drawing functions) is now used only on ye olde PseudoColor displays. The excruciatingly bad and slow implementation of opacities in xxPixmapGraph has been deleted along with the crufty caching code that failed to speed it up.

(Cleanup) Parameters in Graph and subclasses that were misleadingly named "saturation" changed to "opacity."

(Tweak) Turned off interlacing for PNGs, since it always seemed to do more harm than good.

(Code rot) Made XTide work with gpsd 3.x. This is an incompatible change; gpsd 2.9x no longer works.

(Notes) Browser support for SVG is still tricky.

  • Firefox 5
    • If an SVG is embedded using img, Firefox 5 uses jaggy scaling at some zoom levels.
    • Font scaling is inaccurate in the Linux version.
  • Internet Explorer 9
    • If <!DOCTYPE html> is not present at the start of a web page, Internet Explorer 9 pretends not to know what SVG is.
    • Embedding SVG using object is unreliable. It worked in simple tests but failed when used by xttpd.
    • SVG embedding doesn't work for local files (IE behaves differently for the same HTML retrieved from a web server).
  • Other browsers were not tested, as there are enough problems already just getting the top two to work.

XTide 2.11 (2010-08-11)

Comment changes only. The integration with gpsd 2.95 is still dubious after very limited testing, so it's just as well that XTide won't automatically link with gpsd 3.0 when that comes out.

XTide 2.11 RC1 (2010-07-02)

Patches from Trent Piepho:

  • (Feature) Allow use of –ml on xtide command line.
  • (Bug) Fixed memory leak (pixmap leak) in xxMap.
  • (Optimization) Replaced a sqrt with a multiply in xxMap and xxGlobe.

Code changes inspired by patches from Trent Piepho, but more or less different than what was suggested:

  • (Feature) Added –tc and –cc settings to set the color of the dots indicating tide and current stations respectively in the location chooser. (Both formerly used the mark color.) This incurred a new bug: The location chooser depends on a station naming convention to determine which stations are currents. If that convention is not followed, dots may be drawn in the wrong color.
  • (Bug) Fixed WVS dir specified in xtide.conf not working with ––enable-local-files.
  • (Bug) Fixed improper handling of widget internal margins in xxMap that was causing some flat map behaviors to be slightly off.
  • (Semi-bug) Corrected the overly conservative vertical scaling of graphs for stations that have a large number of constituents. This involved changing the method used to estimate tidal range. As a side-effect, stats mode no longer reports the absolute mathematical bounds; it instead reports the new "estimated" bounds, which are tighter but may occasionally be exceeded.
  • (Nits) Changed from truncation to rounding of translated coordinates in xxGlobe and xxMap to avoid the pile-up at zero that truncation produces.
  • (Nits) Added some consts, corrected some comments and help text in xxGlobe and xxMap.

(Feature) Added –ch setting to specify clock height independently from graph height.

(Feature) If gpsd 2.92 or a compatible 2.9x version is present and working, start the location chooser zoomed in on the current GPS fix.

(Usability) Versions of GCC older than 3.4 are now unconditionally rejected by configure.

(Usability) Reject attempts to regenerate the configure script using autoconf 2.65, which has a regression that causes the INT*_T tests to fail improperly.

(Code rot) Fixed resize lag in the newer generation of window managers (including Metacity, Compiz, KWin, Xfwm, and Openbox) that deliver a firehose stream of resize events. (The Xlib Programming Manual says the ConfigureNotify event is to be generated when the resize request "actually completes.")

(Bug) In About mode, X-windows form, implemented line wrapping so that long descriptive text that is not formatted with linebreaks does not result in a ludicrously wide window.

(Code rot) Compatibility with libpng 1.4:

  • Direct access to jmpbuf was deprecated. Use the new macro instead.
  • png_check_sig was replaced by a macro, causing the autoconf test for linking with the library to fail. Use png_sig_cmp instead.

(Portability) Added workaround for GCC Bug #43905 so that XTide can be compiled with GCC 4.5.0.

(Cleanup) Purged leftover xOrigin/yOrigin complexity from xxGlobe.cc.

XTide 2.10 (2008-02-05)

(Code rot) Updated bundled Dstr to version 20080124.

(Documentation) Fixed man page nits and related nits in documentation of command-line switches.

XTide 2.10 RC1 (2008-01-18)

(Feature) Enabled clock mode output (mode k) in PNG and text forms from the command-line client. This feature was requested to enable the construction of embedded clock widgets. (Suggested by Mark Crossley)

(Portability) Fixed incorrect resolution of utsname on Suns. Bug report credit: C. Jeffery Small.

(Code rot) Set the magic environment variable to opt out of the backward-incompatible changes made by the Composite extension to X11. Said changes were causing XTide windows to appear transparent in foo-foo windowing environments. Bug report credit: Alan E. Davis.

(Documentation) Beefed up the man pages and made minor clarifications to the descriptions of some settings.

XTide 2.9.5 (2007-12-10)

(Portability) Renamed CONFIGURE to CONFIGURE-HELP to eliminate conflict on case-insensitive file systems. Bug report credit: Anton Pitts (Mac), Leonid Tochinski (Windows).

(Portability) With help from Leonid Tochinski, made command-line client portable to Visual C++ Express Edition.

  • Tolerate missing header files and functions.
  • Use nonstandard header files if present.
  • Possibly use #pragma message instead of #warning.
  • #define _USE_MATH_DEFINES.
  • Specified binary mode for some files used by tide.exe.
  • Tolerate MS-DOS line discipline in xtide.conf.
  • Some Windows-specific code for low-level file operations.
  • In source files needed for tide.exe, renamed every variable named _timezone to timezoneLocalVar to eliminate conflict with global _timezone variable.
  • Fixed a yyerror signature mismatch between xml_l.ll and xml_y.yy.
  • Added --enable-semicolon-pathsep and --enable-local-files.
  • Possibly use %I strftime format instead of %l.
  • Only if compiling under Visual C++, set locale to "English_United States.1252".
  • Added a workaround for a time function bug in Visual C++ 2005 that causes the program to crash.

XTide 2.9.4 (2007-09-03)

(Bug) Fixed incorrect encoding of characters in "About This Station" window when ambient locale is UTF-8.

(Legal) Relicensed under GPLv3.

(Code rot) configure.ac: Removed –DYY_NO_UNPUT, which flex no longer respects as of version 2.5.33.

(Cleanup) Build scripts: Removed AM_MAINTAINER_MODE and made 'make dist-bzip2' do the right thing.

XTide 2.9.3 (2007-04-17)

(Bug) Fixed dropped lines in flat map drawing (improved version of recent fix to tideEditor).

(Portability) Moved #define __STDC_FORMAT_MACROS to the top of common.hh to avoid a surprise that occurs when inttypes.h gets included by a previous include file.

(Cleanup) Removed an unused #define from common.hh.

XTide 2.9.2 (2007-03-31)

(Bug) In MLLW estimation, possibly include final LLW value depending on endTime.

(Usability) Set year limits for time control dialogs based on the actual type of time_t rather than the conservative interval common to all platforms.

(Usability) Made xttpd report version of XTide; removed obsolete discussion of PNG image format.

(Usability) Catch missing STL at configure time (reportedly not found without CPPFLAGS under Mac OS X 10.4.9).

(Portability) Fixed several nonportable casts in xxGlobe.cc (32-bit int assumption); replaced constant 8 with CHAR_BIT in two places.

(Cleanup) A few more cleanups.

  • Cleaned up config.hh. Most #defines were changed to typed constants. Definitions not related to settings were moved to more appropriate locations.
  • Removed a few includes from common.hh.
  • Cleaned up format strings in Colors.cc.
  • Moved wvsrtv declaration to xxGlobal.hh.

XTide 2.9.1 (2007-03-14)

(Bug) Changed estimation of MLLW in stats mode to use tidal day as specified by Special Publication NOS CO-OPS 1 and 2 instead of solar day as was done in XTide 2.9. It makes about 1 inch of difference.

(Compliance) GNU attributes are now enabled only if one configures with --enable-gnu-attributes. They are only useful if compiling with extra warnings anyway.

(Usability) Compilers that cannot build a particular test case correctly (notably GCC 3.3.x) are now rejected by configure with an explanation that it is time to upgrade.

XTide 2.9 (2007-02-27)

(Portability) Cygwin doesn't have llround yet. Made do without it.

(Compliance) Rearranged some callbacks to avoid the need for objects in the X11 interface to delete themselves (considered harmful) or their containers (presumably worse).

(Cleanup) A few more cleanups.

  • Quashed default copy constructors and assignment operators on classes that did not want to have them.
  • Changed an unsigned char to a bool.
  • Made factories static members of the classes that they produce, thereby eliminating another friend function.
  • Tagged return values as const. See coding conventions.
  • Cleaned up the templates.
  • Got rid of redundant declarations of friend functions.
  • Replaced a magic number with a constant.

XTide 2.9 RC3 (2007-02-18)

(Bug) Stopped time warps on subordinate stations from crashing calendars, AGAIN. The parent class of the class that was junked and rewritten the last time around has been junked and rewritten. Calendar mode has been reimplemented in an entirely different style at great expense and at the last minute.

(Code rot) Fixed configure to detect and use libdstr if it is present.

(Optimization) Inlined some functions and methods to make the highfalutin' C++ code in XTide 2.9 run as fast as the crufty C code in XTide 2.8.3. See commentary in ConstituentSet::tideDerivative for details.

(Usability) Decreased scrolling fraction for flat map from 95% to 25% (consistent with globe). Made station dots bigger in globe (more like map). Made tide graphs scroll by half the width of the graph instead of by 1 day.

(Docs) Added makefile rule to generate README, ChangeLog, NEWS, AUTHORS, and README-QUICK from the web site.

XTide 2.9 RC2 (2007-02-11)

(Feature/Cleanup) Added estimation of MLLW to stats mode; made stats mode text from RC1 more consistent.

(Usability) Improved error reporting to distinguish absence of an HFILE_PATH from absence of harmonics files.

(Cleanup) The C++ standard does in fact promise that the elements of a std::vector are stored contiguously—purged MemoryChunk and replaced its uses with vectors.

(Nits) Fixed a violation of coding conventions; improved commentary in several places.

XTide 2.9 RC1 (2007-02-01)

(Cleanup) 100% code review and major cleanup.

  • Performed numerous major and minor refactorings.
  • Replaced crufty data structures with standard templates.
  • Updated obsolescent coding practices.
  • Corrected improper inheritance relationships.
  • Purged dead, duplicate, and wasteful code.
  • Purged gratuitous complexity and excessive generality.
  • Purged speed hack that was incompatible with the design (hoping that nobody will be impacted by the performance hit).
  • Improved integrity checking.
  • Created enums for cryptic parameters.
  • Used const where applicable.
  • Defined coding conventions.

(Code rot) Installed canonical Dstr. Only visible impact should be different sorting of location names containing æ, ð, ø, ß, or fractions.

(Code rot) Caused xttpd to serve /favicon.ico as expected by most browsers nowadays.

(Code rot) Added support for the newfangled NET_WM protocol to set window titles. This resolves an issue with window titles getting mangled when the ambient locale is UTF-8. Bug report credit: Lutz Mändle.

(Code rot) Converted to automake; updated configure.ac per autoconf 2.60.

(Code rot) Removed Cygwin and Irix workarounds for incomplete strftime implementations. Cygwin's was fixed.

(Optimization) Added a pixel cache to mitigate a performance bottleneck that occurs while anti-aliasing X graphs in xxPixmapGraph.

(Feature) Added LaTeX format for calendar mode and associated settings pagewidth, pageheight, and pagemargin.

(Feature) Added eventmask setting, deprecated nosunmoon setting. Eventmask allows moon phase, sunrise, sunset, moonrise, and moonset to be enabled or disabled individually, whereas nosunmoon only allowed them to be enabled or disabled as a group.

(Feature) Text and HTML form output are now generated in UTF-8 if that is the ambient codeset. Names specified in UTF-8 on the command line are now understood.

(Feature) Text mode graphs and banners now show darkness (night time) in a manner analogous to PNG or X graphs.

(Feature) Mouse wheel (mapped as Button4 and Button5) now works to scroll text prediction windows, location lists, the control panel, and the disclaimer.

(Feature) Added mean of maxima and minima and CPU time to stats mode.

(Feature) Made raw and medium rare modes accessible from xtide command line.

(Feature) Added setting to control whether tide graphs are anti-aliased on true color displays.

(Feature) Added setting to label tenths of units in graphs.

(Feature) Resolved timestamp collision problem in graphs. (1) Shift location of timestamps to avoid collisions when feasible. (2) Improved logic for deciding when to use short descriptions.

(Usability) When failing to load a font, report the name of the font that failed to load. When swapping the begin and end times, inform the user.

(Portability) Used new autoconf feature to obtain integer types with known sizes. Used these types for TIME_WORKAROUND and Interval.

(Compliance) Spun off libtcd into a separate tarball.

(Security) Allow configuring user and group for xttpd and make xttpd exit if the uid/gid can't be set thusly.

(Robustness) Trap and report overflow when adding an Interval to a Timestamp.

(Robustness) Generalized Timestamp::tm2utc and eliminated the last use of libc's mktime. Bad or out-of-range timestamps provided by the user should now reliably yield a relevant error message.

(Robustness) Fixed bug in handling (ignoring) of ill-formed x-fields in TCD.

(Robustness) Modified Graph to be more compatible with variable-width fonts, similar to patch contributed by Lee Ann Rucker.

(Bug) Fixed assertion failure on changing preferred units of length in control panel while a current station is displayed.

(Bug) Fixed xttpd neglecting to demangle %XX syntax in exact query URLs. Bug report credit: James K. Lowden.

(Bug) Fixed window manager closing prediction windows while subordinate dialogs were open, which caused XTide to fail to terminate when the last window was closed.

(Bug) Fixed failure to apply color settings to control panel scrollbar.

(Bugs) Fixed identification of day transitions in rare and pathological cases. Prior to the fix, it was possible for calendar to put events in the wrong day around the time of daylight savings time changes in exotic locales having interesting DST rules.

(Bug) Fixed invalid simplification of current sub stations having slack offsets and level adds that resulted in the slack offsets being ignored for affected stations.

(Bug) Stopped time warps on subordinate current stations from crashing calendars, again. The offending logic is that responsible for figuring how many columns are needed. Said logic has broken repeatedly. This time I basically gave up on the whole approach and dumbed it down to something that hopefully won't break.

(Bug) Fixed incorrect rounding of negative coordinates in graphs. You could notice this in text graphs or banners where column zero sometimes collected an hour tick that should already have scrolled off into negativeland.

(Nit) Remove assertion failure if knots^2 are specified as the units in a sub station record (levelAdd units are always knots anyway).

(Nits) Minor changes in calendar mode text.

(Nit) Fixed off-by-one-second bug in end boundary setting for xttpd calendars.

(Nit) Handle whitespace in HFILE_PATH correctly.

(Nit) In disclaimer, replaced facetious reference to continental drift with serious references to subsidence and uplift.

(Nit) Fixed shifting horizontal alignment of text in X11 text modes.

(Nit) When applying settings in the control panel, preserve marklevels and steps but reset aspect and units to defaults or whatever the new settings specify.

(Nit) Instead of always barfing when HOME is unset, barf only when the need arises to write something to the home directory, and do without any config files that would normally be there.

(Nit) Once again changed descriptive text related to the middle-level line to avoid confusion.

(Nit) Fixed unintended scrolling of X11 text modes triggered in rare circumstances.

(Nit) Fixed X11 graphs and clocks momentarily flashing to background color when updating.

(Nit) Minor changes to short descriptions for tide events.

(Bug) Added documented bug for xttpd logging timezone shift.

(Bug) Added documented bug for control panel vanishing buttons problem.

(Cosmetic) Installed new default icon.

XTide 2.8.3 (2006-03-13)

(Code rot) Made to compile under gcc 4.1.0.

XTide 2.8.2 (2005-01-06)

(Bug) Fixed "oops" in xxMap.cc that caused station dots to be suppressed on part of the flat map. Bug report credit: Jan Depner.

XTide 2.8.1 (2004-12-28)

(Portability) Updated configure to look in lib64 for X libs, for compatibility with x86_64. Bug report credit: Fedora / David Kaplan.

XTide 2.8 (2004-12-10)

(Nit) More intelligent selection of WVS resolutions in globe. The wvs3.dat file now gets use.

(Nit) Don't suppress single-point islands on globe.

XTide 2.8 BETA 2 (2004-11-17)

(Bug) Tried to fix crash on startup on multi-head displays (no feedback on whether it worked).

(Oversight) Omitted slack offsets are now handled by interpolating from known tide events rather than defaulting to reasonable values. This should have been done as part of the changes in Beta 1.

XTide 2.8 BETA 1 (2004-10-26)

(Bug) The subordinate station interpolation algorithm derived from work by Jean-Pierre LaPointe started misbehaving when it met the new NOS data imported 2004-09. See Exhibit A.

Exhibit A: discontinuous tide graph for Hana, Maui

That algorithm was designed around architectural problems that were eliminated in the refactorings of XTide 2.7. Replaced it with a simpler and better algorithm that solves the above problem and three others (appearing below).

The old algorithm had the interesting property that, as a side effect of fudging around pathological cases that broke the algorithm, the graph would often be a more likely model of reality than unquestioning loyalty to the corrections would give. No such luck with the new algorithm, unless I deliberately break it in the same way. See Exhibit B, where an application of offsets to the insignificant higher low and lower high tides at Kahului has produced a significant (and probably mythical) tide cycle at Hana on the evening of 2004-09-08.

Exhibit B: Kahului
Exhibit B: Hana ho

(Bug) Fixed this longstanding documented bug:

Tide graphs and raw output for subordinate current stations won't mesh with the predicted times of slack water, Min Flood or Min Ebb. Cause of bug: The interpolation algorithm used to produce tide graphs for subordinate stations doesn't do slack water. Workaround: none.

(Bug) Removed this longstanding documented limitation:

The raw tide levels for subordinate current locations whose reference stations are hydraulic will do bogus things for a few minutes around the time of slack water. Hydraulic currents exacerbate a minor inaccuracy that exists for all subordinate stations, producing a major inaccuracy.

(Feature) Removed this longstanding documented limitation:

For most subordinate stations, you can't set a mark level.

(Bug?) Changed application of offsets for Min Flood and Min Ebb on subordinate current stations to match what I think is NOS' intent. For details, see https://flaterco.com/xtide/mincurrents.html.

(Bug) Fixed an IMPOSSIBLE_CONVERSION failure (oddly enough, from some units to the same units) triggered by opening a station, converting units, setting a mark level, and then opening a new window from the Options menu. Kudos to August Hahn for discovering the steps to reproduce this "interesting" bug. Added a new warning, NO_CONVERSION, to flag any other occurrences of the same thing.

(Code rot) Added :America/Juneau, :America/Nome, :America/Yakutat and :Pacific/Johnston to the compatibility table for platforms with obsolete zoneinfo. (Deliver me from Solaris 8!)

(Bugs & Features) Upgraded to libtcd 2.0.

(Feature) Added about mode. (As in "About this station")

(Cleanup) Cleaned up strange coding in StationRef, HarmonicsFile, and Offsets left over from the days of XML sub stations.

(Cleanup) Deleted some dead pretty-printing code in Speed, Constituent, etc.; got rid of static buffers in some other pretty-printing code; got rid of the Constituent class (merged into TabulatedConstituent); synced Angle::normalize with fp roundoff fix and assertion from Congen; added an assertion that node factors should be greater than 0 (this will detect TCD files with overflow problems).

(Cleanup) Removed CFLAGS from the build process; just use CXXFLAGS. Removed -DNVSUNOS from configure.in since it has no effect on libtcd.

(Cleanup) Moved libtcd accesses out of TabulatedConstituent. Moved libtcd dependencies out of HarmonicsFile.hh and changed build dependencies so that only HarmonicsFile gets rebuilt when libtcd is changed.

(Bug) Changed "Mean Tide Level" verbiage (formerly "Mean Sea Level") to say "Mean Astronomical Tide." The National Ocean Service (NOS) defines both Mean Sea Level (MSL) and Mean Tide Level (MTL) in terms of averages taken over observations. The line drawn by XTide corresponds to the mathematical mean level of the predictions, which approximates both MSL and MTL, but, strictly speaking, is equivalent to neither.

(Nits) Fixed nits revealed by g++ -Wall -Wextra -pedantic.

(Bug) Fixed a logic error that could cause XTide to lock up if you looked at a period of more than 24 hours with no tide events in just a certain way.

(Feature) Made the globe location chooser able to zoom in closer.

(Nit) In both location choosers, quit chopping lines that are only partly outside the window.

XTide 2.7.1 (2004-08-17)

(Bugs) Incorporated libtcd patch:

Version 1.13
David Flater
2004-08-15

(create_tide_db) Write a valid end_of_file record even if someone creates a database with no tide records.

(tide_db_default) Removed a superfluous space character in table of default datum types (after Lowest Astronomical Tide).

(Evil) Disabled the translation of the TCD comments field into a notes field for sub stations. It was a historical oddity that sub stations had notes but not comments and reference stations had comments but not notes, and this was no excuse for overloading the comments field. Harmbase2 now wants to put stuff in the comments field for sub stations, with the result that XTide 2.7 blabbers the comments to every user as a cryptic and strangely verbose note. Notes will come back if and when the TCD format is extended to include a separate notes field.

XTide 2.7 (2004-08-09)

(Nit) Fixed xttpd to include the file name as well as the revision date when citing what version of which harmonics file it's using.

XTide 2.7 BETA 2 (2004-07-01)

(Portability) Ignore all hidden files (dot files) in a directory indicated by HFILE_PATH, not just "." and "..". (OS X creates hidden files everywhere.)

(Portability) Run ranlib on libtcd.a; ignore error if ranlib isn't there. (OS X needs ranlib.)

(Portability) Changed normalcflags and normalcxxflags in configure.in to say -O instead of -O2. (Forte doesn't grok -O2.)

(Portability) When looking for X11 in configure, recognize libXaw.dll.a (per latest Cygwin) as well as libXaw.so and libXaw.a.

(Nit) Removed unnecessary escaping and quoting in a warning message in configure.in.

XTide 2.7 BETA 1 (2004-04-20)

(Code rot) libtcd 1.12: Deleted #include <malloc.h> from tcd.h.

(Nit) Replaced inappropriate radiation symbols in error windows with standard international symbols for general panic and impending doom.

(Feature) Added iCalendar format and option to get iCalendar output from xttpd.

(Feature) Added cbuttons setting to control whether clock windows appear with buttons by default.

(Feature) Allowed setting location of lone window with -geometry.

(Feature) Allowed specifying an IP address for xttpd.

(Feature) Added CSV format to various modes.

(Portability) Added test for Fedora RPM build environment in configure. If found, usual and customary compiler and linker switches are suppressed and RPM_OPT_FLAGS are added.

(Bug) Fixed small memory leak in SubordinateStation.cc.

(Cleanup) Major refactoring of tide events handling code.

  • Original design: predictExactTideEvent took an "internal" timestamp, scanned for tide events, returned a tide event with "corrected" timestamp (incorporating subordinate station corrections) and also the "uncorrected" timestamp from where scanning for the next event would continue. Complex caching logic was needed to integrate actual tide-tide events with sun and moon events and still return events in the right order... usually. However, sub station corrections could still cause events to be returned out of order, and there was no way to fix it.
  • What happened: Eventually every relevant module except xxTextMode grew its own crufty layer of linked list bashing to post-process the predictions, really get them in the right order, and meet other requirements unique to each module. Circa version 2.6 the cruft achieved critical mass and began to obstruct routine maintenance.
  • The fix: Linked list bashing made redundant by TideEventsOrganizer, which inherits standard multimap template. predictExactTideEvent replaced by predictExactTideEvents, which takes a range of timestamps and populates an organizer with exactly the events falling within that range (no "internal" timestamps required). extendRange adds more events at the beginning or end of an organizer to support scrolling types of behaviors, albeit in chunks instead of single events.
  • Outcome: Cruft greatly reduced. Several previously unfixable bugs were fixed (see below). -b and -e ranges now mean something. Scrolling performance in xxTextMode slightly degraded.

(Bug) Fixed this longstanding documented bug:

There are edge effects at the start and end of an interval chosen for subordinate station predictions. Some events that are inside of the interval may be excluded, and vice-versa. Cause of bug: While the interval is faithfully scanned for the reference station, tide events can jump in or out of the chosen interval after the offsets are applied. Workaround: Leave a margin around the interval of interest that is larger than the offsets of the subordinate station (a few hours should suffice).

(Bug) Fixed this longstanding documented bug:

If two events (e.g., high tide and full moon) happen to coincide very closely, within 1 minute of each other, and you reverse the direction of the scrolling in the interactive plain mode window at a point where only one of the events is visible, you might be able to make the other one disappear. Cause of bug: accuracy of predictions, precision of timestamps. Workaround: don't do that.

(Bug) Fixed this longstanding documented bug:

In the interactive plain mode window only, tide events can be listed out of order for subordinate stations. Cause of bug: design conflict. Efficient scrolling is incompatible with keeping the list sorted. Workaround: save the predictions to a file and they will be sorted.

(Nit) -b and -e ranges now mean specifically "all t such that b <= t < e."

(Nit) Expunged anachronistic references to "text mode" (it's plain mode).

(Bug) Fixed an assertion failure "tidecol < numcol" that could occur generating calendars for pathological subordinate current stations where applying the offsets causes slack-before-flood to happen after max flood or analogous for ebb.

(Nits) Added casts and changed data types to get rid of unsigned-to-signed comparison warnings.

(Cleanup) Major refactoring of settings management code to fix this longstanding "known design problem:"

Nine source files must be changed to add one new setting (Settings.hh, Settings.cc in 3 places, config.hh, UserDefaults.cc, xxApplicationDefaults.cc, ConfigDefaults.cc, CommandLineSettings.cc in 2 places, xxXTideRoot.cc in 4 places, and xxXTideRoot.hh).

XTide 2.6.4 (2003-11-16)

(Bugs) Incorporated libtcd patch:

Version 1.11
David Flater
2003-11-16

(create_tide_db) Fixed horrible bug: offsets for speeds, equilibrium args, and node factors were sign-reversed with respect to their usage in read_tide_db_header and write_tide_db_header, resulting in possible overflows.

(read_tide_db_header) Added handling for zero tide records, which happens on new database create.

(open_tide_db) Added check of modified flag to 2003-10-14 code.

(close_tide_db) Deleted repeat free of tindex introduced 2003-10-14. Cleared modified flag on close.

XTide 2.6.3 (2003-10-14)

(Bug) Incorporated libtcd patch:

Version 1.10
David Flater
2003-10-14

Incorporated patch from Phil Thornton that closes a memory leak and improves performance on repeat calls to open_tide_db. See https://flaterco.com/xtide/tcd_notes.html

(Nit) Added a precompiler directive to prevent code inside of assert statements from being disabled by over-ambitious optimization.

XTide 2.6.2 (2003-09-05)

(Bug) Incorporated libtcd patch:

    Version 1.09
    Jan C. Depner
    2003-09-04

    Bug fix - modifying last record in file and changing size of record caused
    a big problem.

XTide 2.6.1 (2003-07-23)

(Bug) Incorporated libtcd patch:

    Version 1.08
    Jan C. Depner
    2003-07-23

    Bug fix - deleting last record in file caused a big problem.

XTide 2.6 (2003-05-28)

No code changes; just promoted to final release status.

XTide 2.6 BETA 4 (2003-03-27)

(Nit) Updated version string in libtcd.

XTide 2.6 BETA 3 (2003-03-27)

(Bug) There was another problem with the encoding of subordinate stations in TCD files. The only stations materially affected this time were Gnat Cove, Carroll Inlet, Alaska, and Olga Point, Olga Strait, Sitka Sound, Alaska. However, the fix required another incompatible change to the encoding of subordinate stations and updates to affected code in libtcd and XTide. TCD files produced with tcd-utils dated earlier than 2003-03-27 and previous development or beta versions of XTide 2.6 should be replaced to avoid getting incorrect results.

XTide 2.6 BETA 2 (2003-03-18)

(Bugs!) tcd-utils was building some subordinate current stations incorrectly. The fix required an incompatible change to the encoding of slack offsets and updates to affected code in libtcd and XTide. TCD files produced with tcd-utils dated earlier than 2003-03-18 and previous development or beta versions of XTide 2.6 should be replaced to avoid getting incorrect results on subordinate current stations. Except... ironically, it appears that some of the subordinate current stations presently in the database are broken in precisely the same way as one of the TCD bugs, with the result that in those cases, you get the right answer only with the broken code. The issue with those is the bogus assumption that the right thing to do if you don't get slack offsets is set them to zero. If you don't get slack offsets (floodbegins, ebbbegins), OMIT those fields! When slack offsets are omitted, XTide will interpolate a reasonable value. But if you specify zero, you get zero -- even if that's unreasonable given the skew of max and min. (This note has been added to the relevant portion of the documentation.)

XTide 2.6 BETA 1 (2003-02-20)

(Optimization) Changed from ASCII format harmonics files (harmonics.txt and offsets.xml) to binary TCD format (harmonics.tcd); retired the problematic fast loader since all loading now occurs at ludicrous speed. Thanks again to Jan Depner.

(Feature) Added setting to enable inferred constituents (Jan Depner).

(Code rot) Expunged all uses of deprecated C++ streams from the code except for the verbose debugging code that hasn't been used in ages.

(Feature) Added support for the following command line syntactic shortcuts:

  • Arguments can be concatenated with their switches.
  • A yes/no switch that omits its argument implies "y".
  • Using +xx instead of -xx for a yes/no switch inverts the argument (so if the argument is omitted, "n" is implied).

(Feature) Overhauled usage of time_t to allow timestamps to range before 1970 and after 2037. Added TIME_WORKAROUND to enable access to the past and future years on platforms where time_t is 32 bits.

(Portability) Changed default time formats when compiling under Irix to work around lack of support for %l in SGI's strftime implementation. C.f., similar Cygwin bug fixed in XTide 2.5 BETA 1 (2002-05-21) and the "fix" that started it all in XTide 2.4 BETA 1 (2001-03-25). What a pain.

(Nits) Gave the control panel a scrollbar. Stabilized the layouts of the control panel, text, raw, and medium rare modes. Merged xxRareModes into xxTextMode.

(Feature) Replaced the now mostly useless filename field in location lists with a type field (reference or subordinate).

(Feature) The zone at the bottom of tide graphs previously used to note slack and mark crossing events is now shared by moon events. The date was replaced with a description that is abbreviated when things get crowded.

(Feature) Added moonrise, moonset.

XTide 2.5 (2002-07-14)

(Nit) Tweaked some verbiage in the control panel.

XTide 2.5 BETA 1 (2002-05-21)

(Portability) Tweaked autoconfig files to allow clean compilation under OS X. Thanks to Martin Hofmann.

(Portability) Changed default time formats when compiling under Cygwin to work around lack of support for %l and %Z formats by Cygwin's strftime implementation.

(Feature) Added medium rare mode.

(Feature) Made raw and medium rare modes accessible from the GUI.

(Feature) Incorporated new globe code, which added coastlines and a new flat map projection, from Jan C. Depner.

(Feature) Allowed switching between Cylindrical Equidistant and Orthographic Projections. Added setting to specify user's preference (flatearth).

(Feature) Globe now rotates on two axes, and both globe and map include latitude and longitude readouts.

(Feature/Portability) Incorporated patch from John Holden to improve xttpd user interface for requesting tide calendars and to work around an Alpha-specific bug in timestamp rendering.

(Code rot) Updated :America/Iqaluit, :America/Mexico_City, and :Mexico/General in time zone compatibility table.

(Bug) "Mean Sea Level" verbiage corrected to say "Mean Tide Level." Identifiers containing msl were not renamed.

(Nit) Updated disclaimer text.

(Nit) Cleaned up xxTimestamp. N.B., newer versions of Athena Widgets now show two columns of choices where pull-down buttons used to run off the screen, so the "tiny font" previously used for some of the choices is no longer used here. It is still used in the clock icon.

(Nit) Added a line to the 'install' target of Makefile.in to create the target directories if they do not exist.

XTide 2.4 (2001-05-09)

(Bug) Fixed an OLD memory management bug in Dstr.cc. Thanks to Phil Thornton.

XTide 2.4 BETA 2 (2001-04-15)

(Bug) xttpd did not supply a robots.txt page. Added robots.txt patch from John Stanley.

XTide 2.4 BETA 1 (2001-03-25)

(Feature) Enhanced HFILE_PATH to enable searching of directories.

(Bug) Removed, or at least improved, a kludge in Timestamp that was preventing 24-hour time users from getting leading zeros on hours. A compensatory change to the default time and hour formats was also made.

(Nit) Updated example in NO_HFILE_PATH error message again.

(Tuning) Reduced fastload limit to 2.

(Feature) Xttpd now shows the versions of the harmonics files that it's using on its main page.

(Feature) Added a note attribute to subordinate station XML.

(Optimization) Incorporated patch to squeeze out null constituents.

XTide 2.3 (2000-12-08)

No code changes; just promoted to final release status.

XTide 2.3 BETA 2 (2000-10-01)

(Code rot) Added :America/Belem, :America/Fortaleza, and :America/Maceio and revised abbreviation for :America/Sao_Paulo in time zone compatibility table.

(Compliance) Smashed case in all (I hope) HTML markup tags for XHTML compatibility (sugg. Richard Kennedy).

(Nit) Typographical tweaks in xttpd.

XTide 2.3 BETA 1 (2000-09-03)

(Feature) Replaced calendar mode with a clone of the much more popular one that Dean Pentcheff has been using on his web site. The "old" calendar mode is still available from tide as -m C.

(Feature) Added setting to suppress sunrise, sunset, moon phases.

(Code rot) Added :America/Goose_Bay to timezone compatibility table.

(Nit) Updated example in NO_HFILE_PATH error message.

XTide 2.2.2 (2000-07-30)

(Compliance) To comply with XML 1.0, the offsets.xml file was changed to have a single "root" document element. As a result, XTide 2.2.1 and earlier cannot find the stations in it. This patch enables XTide to read either old or new offsets.xml files. The prolog of .xtide.xml written by XTide is also made compliant.

XTide 2.2.1 (2000-07-16)

(Code rot) Added :America/Hermosillo and :America/Iqaluit to the zoneinfo compatibility table.

XTide 2.2 (2000-01-12)

No code changes; just promoted to final release status.

XTide 2.2 BETA 1 (1999-12-12)

(Compliance) Xttpd now backgrounds itself and logs to the syslog facility.

(Feature) Added /etc/xtide.conf as alternative to setting HFILE_PATH. The format of this should probably be XML to guard against future expansion, but for now it is as contributed from Debian (Peter Galbraith).

(Feature) Ditched Imake for Autoconf, which simplifies installation.

(Feature) Installed a Unicode-esque collating sequence for Latin1.

(Feature) xttpd: applied location lookup patch from John Holden. This enables URLs of the form http://whatever/locations/name in addition to the more reliable http://whatever/locations/nnn.html syntax. The name-based URLs are not promulgated by xttpd itself. The new syntax is documented in a new hints & tricks page served by xttpd.

(Feature) If you set the environment variable XTIDE_DEFAULT_LOCATION, it works like the default location feature of XTide 1.

(Robustness) Improved resolution of reference stations for subordinate stations to eliminate many SUB_SUBORDINATE errors. Fast loading is still sensitive to the ordering of HFILE_PATH.

(Code rot) Added an autoconf step to deal with mutually incompatible requirements of different platforms on the signature of the accept() function as used in xttpd.cc.

(Code rot) Added Antarctic time zones to the compatibility table in Timestamp.cc.

(Compliance) Changed packaging from xtide2/* every time to xtide-X.Y.Z/*. Changed suggested disposition of xttpd from bin to sbin. Changed xttpd man page section from 1 to 8. Changed suggested disposition of harmonics files from /etc to /usr/local/share/xtide.

(Compliance) Moved some static functions into externC.cc with appropriate signature changes to placate the Sun compiler's anachronism checker.

(Portability) Added workaround for bug in Sun WorkShop Compiler C++ SPARC Version 5.000. Thanks to Raphael Malyankar.

(Nit) Applied patch from Peter Galbraith to set background color in xttpd to white.

XTide 2.1.7 (1999-08-14)

(Bug) Fixed drawing of Latin1 characters. This involved increasing the font height by one row, which will cause minor but noticeable changes in the placement of text.

(Portability) Changed backlog parameter for socket in xttpd.cc from 0 to 5. Digital Unix would accept no connections if backlog was 0. Thanks to Giuseppe Cabras.

XTide 2.1.6 (1999-08-09)

(Bug) Fixed xttpd assertion failure when subordinate stations don't supply time zones.

(Bug) Made RGBGraph stop crashing when it's asked to draw characters that it doesn't know. To do, teach RGBGraph to draw the entire Latin1 character set.

(Portability) Messed with usage of select() in xttpd.cc to try to make it more portable. Giuseppe Cabras reported trouble with it under Digital Unix.

(Portability) Added Imakefile.hp from Christopher Caldwell.

XTide 2.1.5 (1999-07-22)

(Portability) Cleaned up overloading ambiguities and ANSI compliance problems encountered with HP aC++ B3910B A.01.18 (HP-UX 10.20). Thanks to Christopher Caldwell.

XTide 2.1.4 (1999-05-17)

(Portability) Got rid of some dubious implicit conversions between PredictionValue::Unit and its encapsulated enum. Don't know if they were strictly conforming or not, but they made the latest Sun compiler use the wrong constructor. This showed up as UNRECOGNIZED_UNITS errors when trying to load a tide station.

XTide 2.1.3 (1999-05-16)

(Code rot) Stopped including stream.h in common.hh. It was always redundant with iostream.h, but now stream.h has vanished from Sun's latest compiler.

XTide 2.1.2 (1999-03-15)

Add support for color specifications having the deprecated #RRGGBB format, which recently resurfaced on Debian.

Patch from Falk Hueffner for Timestamp::tm2utc. On his Alpha (BSD?), time_t is 64 bits but gmtime returns NULL if the time_t is out of a certain range, which was leading to segfaults.

Fixed reporting of MKTIME_FAILED errors caused by bad timestamps on the -b and -e switches.

XTide 2.1.1 (1999-01-24)

Patch to get rid of all of the references to universe.digex.net that appeared in the sources and documentation. No functional changes.

XTide 2.1 (1998-12-20)

Implemented something similar to a patch sent by Thomas Dean to enable the direction of current that he provided in his XML offsets to be displayed in the boilerplate of text output. Making it work for reference stations is deferred until whenever reference stations are migrated to XML and the new attributes can conveniently be added.

Removed $(DEPXPMLIB) from xtide dependencies (DEPLIBS1 in manifest) to get rid of this needless compilation failure:

make: *** No rule to make target `/usr/X11R6/lib/libXpm.a', needed by `xtide'.  Stop.

The cause of this was that some Linux distributions only provide a shared libXpm, while the dependencies generated by Imake check for the existence of the static library.

Made -o switch append instead of overwrite files per request from AED.

XTide 2.0.1 (1998-10-04)

Fixed a bug reported by Alan Davis which caused access violations and other problems when a default center longitude was set in the control panel.

XTide 2.0 (1998-07-28)

No code changes; just promoted to final release status.

XTide 2.0 Beta.3 (1998-06-28)

Reversed order of location list latitude sort so that points north appear at the top (sug. Dave Davey).

XTide 2.0 Beta.2 (1998-06-02)

SGI portability fix from David Warren: changed declarations of nested structs in header files to use Classname::structname instead of struct structname.

XTide 2.0 Beta.1 (1998-06-01)

First versioned release of XTide 2.


Appendix A — Historical predictions and Y2038 compliance

As of 2002, the average Unix used a signed 32-bit integer to represent time as a count of seconds since 1970-01-01 00:00:00Z. The limits of that representation are 1901-12-13 20:45:52Z and 2038-01-19 03:14:07Z. Some platforms instead used an unsigned 32-bit integer (time starts in 1970) while others already used 64-bit integers.

XTide originally limited itself to the range 1970 to 2037. This provided portability and reliable results regardless of the time_t representation and allowed Interval (the difference between two timestamps) to be represented using a signed 32-bit integer. However, an increasing number of requests for historical "past predictions" combined with slow progress in migrating the average Unix platform to a time representation capable of surviving year 2038 finally motivated the incorporation of a workaround.

As of 2013, signed 64-bit time_t is provided by 64-bit Linux and unsigned time_t has fallen by the wayside. The workaround remains useful on 32-bit Linux, DOS, and Windows. Windows actually uses a signed 64-bit time_t, but the Run-Time Library barfs on dates before 1970 anyway. Go figure.

If XTide is compiled with the workaround, time_t is unconditionally defined as a signed 64-bit integer and the platform's time functions are bypassed. Years from 1 to 4000 are allowed. However, time zones and daylight savings time are sacrificed. Everything becomes UTC. *

The workaround can be enabled at configure time using configure --enable-time-workaround. The range of years that is selectable in timestamp dialogs is automatically expanded to 1700 to 2100 when the time workaround is enabled. If a different range is required, the definitions of Global::dialogFirstYear and Global::dialogLastYear in Global.cc must be changed manually.

In order to obtain predictions for past and future years, it is also necessary to use a harmonics file that supports those years. The new harmonics file harmonics-dwf, rev. 2004-10-05 or later, supports the years 1700 to 2100. If you need to extend the range of years further, use the following procedure.

  1. Obtain and build the most recent versions of Congen, Tcd-utils and Harmbase2, available at https://flaterco.com/xtide/files.html. You will also need to install the version of Postgres indicated by the Harmbase2 instructions.
  2. Obtain the most recent Postgres database dump of harmonics-dwf from the same place and load it: createdb harmbase2; psql harmbase2 < harmonics-dwf-*.sql.
  3. Export the database to a new TCD file using the export program of Harmbase2, specifying whatever years you wanted: export -b 1700 -e 2300 harmonics-me.

If you are using .txt and .xml files, you can extend the range of years as follows.

  1. Obtain and build the most recent versions of Congen and Tcd-utils, available at https://flaterco.com/xtide/files.html.
  2. Generate the needed years as explained in the README in the Congen distribution. E.g., congen -a1 -b 1700 -e 2300 < congen_input.txt > out.txt.
  3. Using a text editor, edit harmonics.txt and replace the segment between "Begin congen output" and "End congen output" with the congen output that you just generated.
  4. Convert the data to TCD format using build_tide_db as explained in the README of the Tcd-utils distribution.

Please be aware that extrapolating predictions over large spans of time may give extremely inaccurate results. Don't even go there until you read this FAQ about it.

* The time scale used by the time workaround is not strictly speaking UTC since it does not implement leap seconds, but neither does the standard library. See Limitation #5.


Appendix B — Application of offsets for Min Flood and Min Ebb events

B.1 Background
B.2 Secondary Station Adjustments Instructions (NOS)
B.3 Comparison of old and new results
B.4 Comparison with published tables

Background

XTide distinguishes the following common events for current stations:

Max Flood | Maximum current in the flood (+) direction.
Max Ebb | Maximum current in the ebb (−) direction.
Slack, Flood Begins | Zero current preceding flood.
Slack, Ebb Begins | Zero current preceding ebb.

Additionally, it distinguishes two events that are not seen as frequently:

Min Flood | Minimum current in the flood (+) direction between two Max Floods when the current never crosses zero.
Min Ebb | Minimum current in the ebb (−) direction between two Max Ebbs when the current never crosses zero.

In XTide 2.8, a change was made to the application of offsets for Min Flood and Min Ebb events.

Event | XTide 2.7 time adjust | XTide 2.7 current adjust | XTide 2.8 time adjust | XTide 2.8 current adjust
Min Flood | Same as Max Ebb | Same as Max Ebb | Same as Slack, Flood Begins; if null, use Max Flood | Same as Max Flood
Min Ebb | Same as Max Flood | Same as Max Flood | Same as Slack, Ebb Begins; if null, use Max Ebb | Same as Max Ebb

This change was made based on a reading of the highlighted sections of the National Ocean Service web page quoted below, which was downloaded from http://co-ops.nos.noaa.gov/currents04/t2chelp.html on 2004-09-15.

The second highlighted passage states that no attempt is made to predict the speed of the minimum currents. It would not make sense for XTide to leave these values unadjusted because a very small ratio could cause the supposed maxima to have lower amplitude than the minimum. Applying the ratio used for the surrounding maxima will give reasonable looking results as long as the adjustment is only a ratio. (Additive adjustments would not produce reasonable results.)

BEGIN NATIONAL OCEAN SERVICE TEXT (highlighting added)

Secondary Station Adjustments Instructions

The publication of full daily predictions is necessarily limited to a comparatively small number of stations. These stations are referred to as "reference stations". Tidal current predictions for more than 2500 other locations can be obtained by applying certain differences to the daily predictions for the reference stations.

These pages provide a listing of the more than 2500 "subordinate stations" for which such predictions can be made, the differences and ratios to be used, and a link to the appropriate reference station. The stations in the listing are arranged geographically to make it possible to find stations which are available for an area you are interested in.

Since all tidal current stations are located offshore, many of them are named for the channels, rivers, and inlets they are located in, or for cities, towns, or navigational points they are located near. Some personal knowledge of the area you are interested in may be necessary to determine which station(s) are most appropriate for your use.

Depths: Although current measurements may have been recorded at various depths in the past, the data listed here for most subordinate stations are mean values determined to have been representative of the current at each location. For that reason, no specific current meter depth for those stations are given. Beginning with the Boston Harbor tidal current survey in 1971, data for individual meter depths were published and subsequent new data may be presented in a similar manner.

Since most of the current data in these pages came from meters suspended from survey vessels or anchored buoys, the listed depths are those measured downward from the surface. Some later data have come from meters anchored at fixed depths from the bottom. These meter positions were defined as depth below chart datum. Such defined depths in these pages will be accompanied by the small letter "d".

Minimum Currents: The user may note that at many locations the current may not diminish to a true slack water or zero speed stage. For that reason, the phrases, "minimum before flood" and "minimum before ebb" are used in these pages rather than "slack water" although either or both minimums may actually reach a zero speed value at some locations.

Maximum Currents: Near the coast and in inland waters, the current increases from a minimum current (slack water) for a period of about 3 hours until the maximum speed or strength of the current is reached. The speed then decreases for another period of about 3 hours when minimum current is again reached and the current begins a similar cycle in the opposite direction. The current that flows towards the coast or up a stream is known as the flood current; the opposite flow is known as the ebb current. Speeds of the current at reference stations are listed as positive values for floods and negative values for ebbs. These pages list the average directions of the maximum floods and maximum ebb currents. The directions listed are given in degrees, true, reading from 000 at north to 359 and are the directions toward which the current flow.

Differences and Speed Ratios: These pages contain time differences by which the user can compile approximate times for the minimum and maximum current phases at the subordinate stations. Time differences for those phases should be applied to the corresponding phases at the reference station. It will be seen upon inspection that some subordinate stations exhibit either a double flood or a double ebb stage, or both. In those cases, a separate time difference is listed for each of the three flood (or ebb) phases and should be applied only to the maximum flood (or ebb) phase at the reference station. The results obtained by the application of time differences will be based upon the local time meridian. Differences of time meridians between a subordinate stations and its reference station have been accounted for.

The speed ratios are used to compile approximations of the daily current speeds at the subordinate stations and refer only to the maximum floods and ebbs. No attempt is made to predict the speed of the minimum currents. These ratios are multiplied to the corresponding maximum current phases at the reference station. As mentioned before, however, some stations may exhibit either a double flood or a double ebb, or both. As with time differences, separate ratios are listed for each of the three flood (or ebb) phases and should be applied only to the daily maximum flood (or ebb) speed at the reference station. It should be noted that although the speed of a given current phase at a subordinate station is obtained by reference to the corresponding phase at a reference station, the directions of the current at the two places may differ considerably. These pages list the average directions of the maximum current phases at the subordinate stations.

Example Tidal Current Calculations

For Cape May Channel, the time and speed adjustments listed in the tables are:

Minimum       Minimum         Speed
Before Flood  Before  Ebb     Ratio
Flood         Ebb           Flood Ebb
-1 14  -1 30  -1 11  -0 45   1.1  1.8

and the reference station is Delaware Bay Entrance. If the times and speeds listed in column 1 are the minimum and maximum tidal currents for a day at Delaware Bay Entrance, column 2 are the time corrections, and column 3 are the speed corrections; column 4 will be the predicted currents at Cape May Channel. These values are computed by adding or subtracting the times in column 1 to the adjustments in column 2; and by multiplying the speeds in column 1 by the ratios in column 3.

     (1)                 (2)        (3)         (4)
  Times     Speed                            Times     Speed
0114  0425   1.3    -1 14  -1 30   *1.1    0000  0255   1.4
0736  1055  -1.3    -1 11  -0 45   *1.8    0625  1010  -2.3
1351  1650   1.2    -1 14  -1 30   *1.1    1237  1520   1.3
1958  2316  -1.3    -1 11  -0 45   *1.8    1847  2231  -2.3
END NATIONAL OCEAN SERVICE TEXT

Comparison of old and new results

From http://co-ops.nos.noaa.gov/currents04/tab2pc2.html (2004-09-15):

                                                              Minimum       Minimum         Speed    Direction
                                                              Before Flood  Before  Ebb     Ratio    At Maximum
Station                                              Depth    Flood         Ebb           Flood Ebb  Flood Ebb  Reference Station
Admiralty Head, 0.5 mile west of                              -0 31  -0 03  +0 01  -0 07   1.3  1.2   145  025  Admiralty Inlet

Resulting XTide data set:

Name | Admiralty Head, 0.5 mile west of, Washington Current
Reference | Admiralty Inlet, Washington Current
Max time add | -00:03
Max level add | NULL
Max level mult | 1.300
Min time add | -00:07
Min level add | NULL
Min level mult | 1.200
Flood begins | -00:31
Ebb begins | +00:01

NOS predictions for 2004-09-08 and 2004-09-09 at reference station, from http://co-ops.nos.noaa.gov/currents04/ADMIRALI.shtml (2004-09-15):

    Slack    Maximum   Slack    Maximum   Slack    Maximum   Slack    Maximum   Slack    Maximum
    Water    Current   Water    Current   Water    Current   Water    Current   Water    Current
Day  Time  Time  Veloc  Time  Time  Veloc  Time  Time  Veloc  Time  Time  Veloc  Time  Time  Veloc
     h.m.  h.m.  knots  h.m.  h.m.  knots  h.m.  h.m.  knots  h.m.  h.m.  knots  h.m.  h.m.  knots

  8         402   -2.3   814  1122    1.5  1449  1801   -1.2        2257   -0.1
  9         508   -2.4   909  1219    1.7  1543  1856   -1.5

Corresponding XTide results:

Reference station Sub station (XTide 2.7) Sub station (XTide 2.8)
2004-09-08  4:02 AM PDT  -2.33 knots  Max Ebb
2004-09-08  8:13 AM PDT   0.00 knots  Slack, Flood Begins
2004-09-08 11:22 AM PDT   1.51 knots  Max Flood
2004-09-08  2:48 PM PDT  -0.00 knots  Slack, Ebb Begins
2004-09-08  6:01 PM PDT  -1.22 knots  Max Ebb
2004-09-08 10:57 PM PDT  -0.07 knots  Min Ebb
2004-09-09  5:08 AM PDT  -2.36 knots  Max Ebb
2004-09-09  9:08 AM PDT   0.00 knots  Slack, Flood Begins
2004-09-09 12:19 PM PDT   1.71 knots  Max Flood
2004-09-09  3:42 PM PDT  -0.00 knots  Slack, Ebb Begins
2004-09-09  6:56 PM PDT  -1.47 knots  Max Ebb
2004-09-09 11:22 PM PDT   0.00 knots  Slack, Flood Begins

2004-09-08  3:55 AM PDT  -2.80 knots  Max Ebb
2004-09-08  7:42 AM PDT   0.00 knots  Slack, Flood Begins
2004-09-08 11:19 AM PDT   1.96 knots  Max Flood
2004-09-08  2:49 PM PDT  -0.00 knots  Slack, Ebb Begins
2004-09-08  5:54 PM PDT  -1.47 knots  Max Ebb
2004-09-08 10:54 PM PDT  -0.09 knots  Min Ebb
2004-09-09  5:01 AM PDT  -2.84 knots  Max Ebb
2004-09-09  8:37 AM PDT   0.00 knots  Slack, Flood Begins
2004-09-09 12:16 PM PDT   2.22 knots  Max Flood
2004-09-09  3:43 PM PDT  -0.00 knots  Slack, Ebb Begins
2004-09-09  6:49 PM PDT  -1.77 knots  Max Ebb
2004-09-09 10:51 PM PDT   0.00 knots  Slack, Flood Begins

2004-09-08  3:55 AM PDT  -2.80 knots  Max Ebb
2004-09-08  7:42 AM PDT   0.00 knots  Slack, Flood Begins
2004-09-08 11:19 AM PDT   1.96 knots  Max Flood
2004-09-08  2:49 PM PDT  -0.00 knots  Slack, Ebb Begins
2004-09-08  5:54 PM PDT  -1.47 knots  Max Ebb
2004-09-08 10:58 PM PDT  -0.08 knots  Min Ebb
2004-09-09  5:01 AM PDT  -2.84 knots  Max Ebb
2004-09-09  8:37 AM PDT   0.00 knots  Slack, Flood Begins
2004-09-09 12:16 PM PDT   2.22 knots  Max Flood
2004-09-09  3:43 PM PDT  -0.00 knots  Slack, Ebb Begins
2004-09-09  6:49 PM PDT  -1.77 knots  Max Ebb
2004-09-09 10:51 PM PDT   0.00 knots  Slack, Flood Begins

Comparison with published tables

When the change in XTide's behavior was made in 2004, the NOS web site did not provide calculated predictions at the subordinate stations for comparison. Upon reviewing the issue in 2007 (at which time those predictions were available), it was found that the published tables did neither of the behaviors that were implemented in XTide.

Time offsets applied to Min Ebb event
XTide 2.7 | XTide 2.8 | NOS 2007
Flood | Minimum Before Ebb | Ebb

Whereas the behavior of the published tables seemed to be in conflict with the Secondary Station Adjustments Instructions, it was resolved not to change the behavior of XTide at that time.

Reference station

NOS table copied from http://tidesandcurrents.noaa.gov/get_predc.shtml?year=2007&stn=6030+Admiralty+Inlet&fldavgd=179&ebbavgd=003&footnote= 2007-02-24

Admiralty Inlet
Predicted Tidal Current | March, 2007
Flood Direction, 179 True. | Ebb (-)Direction, 003 True.
NOAA, National Ocean Service
 | Slack Water | Maximum Current |  | Slack Water | Maximum Current |  | Slack Water | Maximum Current |  | Slack Water | Maximum Current |  | Slack Water | Maximum Current
Day | Time h.m. | Time h.m. | Veloc knots | Time h.m. | Time h.m. | Veloc knots | Time h.m. | Time h.m. | Veloc knots | Time h.m. | Time h.m. | Veloc knots | Time h.m. | Time h.m. | Veloc knots
12 | 0049 | 0347 | -0.9 |  | 0825 | -0.1 |  | 1458 | -2.4 | 1917 | 2229 | +1.5
13 | 0207 | 0512 | -1.0 |  | 0948 | -0.2 |  | 1610 | -2.4 | 2019 | 2335 | +1.8

Comparable XTide output, using harmonics-rmk-20040615.tcd
tide -l"admiralty inlet" -b"2007-03-12 00:00" -e"2007-03-14 00:00" -mc -empSsMm -tf"%H%M" -fh

Day | Slack | Flood | Slack | Ebb | Slack | Flood | Slack
Mon 12 |  |  | 0048 | 0347 −0.93 kt 0824 −0.08 kt 1457 −2.41 kt | 1916 | 2229 1.52 kt |
Tue 13 |  |  | 0206 | 0512 −1.04 kt 0948 −0.18 kt 1610 −2.45 kt | 2018 | 2335 1.75 kt |

Subordinate station

Name             Agate Pass, North End of, Washington Current
Reference        Admiralty Inlet, Washington Current
Min time add     -0:59
Min level add    NULL
Min level mult   0.700
Max time add     -1:00
Max level add    NULL
Max level mult   0.800
Flood begins     -1:28
Ebb begins       -0:18

NOS table copied from http://tidesandcurrents.noaa.gov/get_predc.shtml?year=2007&stn=6030+Admiralty+Inlet&secstn=Agate+Passage,+north+end&sbfh=%2D1&sbfm=28&fldh=%2D1&fldm=00&sbeh=%2D0&sbem=18&ebbh=%2D0&ebbm=59&fldr=0.8&ebbr=0.7&fldavgd=230&ebbavgd=032&footnote= 2007-02-24

Agate Passage, north end
Predicted Tidal Current | March, 2007
Flood Direction, 230 True. | Ebb (-)Direction, 032 True.
NOAA, National Ocean Service
 | Slack Water | Maximum Current |  | Slack Water | Maximum Current |  | Slack Water | Maximum Current |  | Slack Water | Maximum Current |  | Slack Water | Maximum Current
Day | Time h.m. | Time h.m. | Veloc knots | Time h.m. | Time h.m. | Veloc knots | Time h.m. | Time h.m. | Veloc knots | Time h.m. | Time h.m. | Veloc knots | Time h.m. | Time h.m. | Veloc knots
12 | 0031 | 0248 | -0.6 |  | 0726 | -0.1 |  | 1359 | -1.7 | 1749 | 2129 | +1.2
13 | 0149 | 0413 | -0.7 |  | 0849 | -0.1 |  | 1511 | -1.7 | 1851 | 2235 | +1.4

Comparable XTide output, using harmonics-rmk-20040615.tcd
tide -l"Agate Pass, North End of, Washington Current" -b"2007-03-12 00:00" -e"2007-03-14 00:00" -mc -empSsMm -tf"%H%M" -fh

Day | Slack | Flood | Slack | Ebb | Slack | Flood | Slack
Mon 12 |  |  | 0030 | 0248 −0.65 kt 0806 −0.06 kt 1358 −1.69 kt | 1748 | 2129 1.21 kt |
Tue 13 |  |  | 0148 | 0413 −0.73 kt 0930 −0.13 kt 1511 −1.71 kt | 1850 | 2235 1.40 kt |


Appendix C — Making calendars fit onto a single page

Get rid of unwanted information

Regardless of which format you are using, having extra stuff in the calendar that you don't want isn't going to help. If you are using a web page somewhere, look for options that allow you to suppress sun and moon events or control the formatting of timestamps. If you are using XTide directly, you do this using various settings. The following examples assume command line usage, but you can change settings in several other ways. See settings for details.

To get rid of unwanted columns for sun and moon events, use the –em command line switch to set an event mask. E.g, to suppress all sun and moon events, set the event mask to the value pSsMm. p = phase of moon, S = sunrise, s = sunset, M = moonrise, m = moonset.

To get rid of unwanted verbosity in timestamps (AM/PM and/or time zone), use the –tf command line switch to set the time format string. E.g., to reduce it to four digits of 24-hour notation, set the time format string to %H%M. To keep AM/PM but lose the time zone, set the time format string to %l:%M %p.

Other settings added in XTide 2.14 can be used to condense or tweak calendar text:

  • The omitunits setting (–ou) prints numbers with no ft/m/kt and adds a header line stating the units and datum (where possible). Say -ou y to omit the units.
  • The caldayfmt setting (–cf) controls the format string used to print days in calendars. To omit the day of week and just keep the number, specify %d.
  • The linebreak setting (–lb) controls whether or not calendar mode inserts a line break before prediction values. This reduces truncation in text format and tweaks line wrapping in HTML and LaTeX formats.
  • The pagebreak setting (–pb) controls whether or not calendar mode inserts a page break and repeats the station header for each month in text, HTML, and LaTeX formats. Text uses form feeds and HTML uses a page-break-before style.

Scale down HTML

If the calendar that you want to print is on a web page or otherwise in HTML format, the next step is to set up your print scaling to make it fit on the page without a lot of ugly text wrapping. The process for doing this is slightly different depending on your browser.

Firefox

Do File → Print Preview. Use the controls at the top of the window to select Portrait or Landscape printing and to scale down the HTML until it fits nicely on a page. When ready, select Print.

Internet Explorer

  1. Read this: How to use Print Preview
  2. Pull down the print size menu ( Shrink To Fit) and try different options until the calendar fits nicely on a page.
  3. When ready, click on the tiny printer icon to print.

Get serious—use LaTeX

The problem with printing calendars from HTML is that HTML was designed for viewing on a monitor. Whether the result ends up on one page or three when you print it was never supposed to be a concern. The concept of pagination eventually appeared in style options, but it was never a priority.

The right language to use in this case is LaTeX. Like HTML, LaTeX is a markup language, but it is designed for typesetting printed documents.

XTide can generate calendars in LaTeX format. These can be converted to PDFs using pdflatex, and those PDFs can then be printed on any size paper using Adobe Reader.

If you are using XTide through a web page, you just have to hunt for an option to generate a PDF and hope that there is one.

The process to generate and view a PDF from the command line is as follows:

bash-3.00$ tide -l"Location Name" -mc -fl -b"Start Time" -e"End Time" > cal.tex
bash-3.00$ pdflatex cal.tex
bash-3.00$ acroread cal.pdf

The default page geometry in LaTeX mode is probably not optimal for making your calendar look nice. Experiment with different values for pageheight (–ph 420) and pagewidth (–pw 297) until the calendar looks nice in PDF. Do not worry that the shape of the pages in the PDF is not what you have in your printer.

Example of nicely formatted calendar

When you are happy with the look of the PDF, do the following to print it.

Adobe Reader

Different versions of Adobe Reader present the same options in different ways. On the File → Print menu, do whichever applies:

  1. Under Size Options, check Fit, and check Auto portrait/landscape.
  2. Change Page Scaling to Fit to Printable Area, and check Auto-Rotate and Center.


About this tide - Tide Gauge Cleat

Winter Harbor, ME

Tide Gauge Cleat

— David Flater (dave@flaterco.com)


About this tide - Cleat1047

Winter Harbor, ME

— David Flater (dave@flaterco.com)


About this tide - Dike Brook

— David Flater (dave@flaterco.com)


About this tide - Old House Cove

ANP, Trenton, ME

— David Flater (dave@flaterco.com)


libcongen header file

https://flaterco.com/xtide/files.html#experts

// -*- c++ -*-
// $Id: Congen 2632 2007-08-18 21:30:29Z flaterco $

/*  congen:  constituent generator.
    Copyright (C) 1997  David Flater.

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.
 */

#ifndef CONGEN_HEADER
#define CONGEN_HEADER

#include <stdint.h>
#include <valarray>
#include <string>
#include <vector>
#include <istream>

// This file is (or was) automatically mangled to get rid of UTF-8
// characters like Greek letters and subscripts.  As of g++ 4.2.0,
// Greek letters in identifiers can be made to work (technically, if
// not readably) by translating them to \uNNNN syntax and using the
// -fextended-identifiers switch, but subscripts, primes, and double
// primes are still rejected by the compiler.
// "error: universal character \u2081 is not valid in an identifier"

/* The reader is assumed to be familiar with the following
   publication, hereafter referred to as "SP 98:"

   Manual of Harmonic Analysis and Prediction of Tides.  Special
   Publication No. 98, Revised (1940) Edition (reprinted 1958 with
   corrections; reprinted again 1994).  United States Government
   Printing Office, 1994.

   SP 98 does not cover Doodson-style constituents.  If using those,
   the following publication may be helpful:

   Foreman, M.G.G., 1977.  Manual for Tidal Heights Analysis and
   Prediction.  Pacific Marine Science Report 77-10, Institute of
   Ocean Sciences, Patricia Bay, Sidney, B.C. (2004 revision).
*/

// Apart from the names of the constituents, the following
// astronomical terms from SP 98 are used in this header file:

// (Vₒ+u)   Constituent argument at beginning of a tidal series
// f        Node factor

// V        Principal portion of constituent argument
// T        Hour angle of mean sun
// s        Mean longitude of moon
// h        Mean longitude of sun
// p        Mean longitude of lunar perigee
// p₁       Mean longitude of solar perigee

// u        Part of constituent argument depending upon variations in
//          obliquity of lunar orbit
// ξ        Longitude in moon's orbit of lunar intersection
// ν        Right ascension of lunar intersection
// ν′       Term in argument of lunisolar constituent K₁
// 2ν″      Term in argument of lunisolar constituent K₂
// Q        Term in argument of constituent M₁
// R        Term in argument of constituent L₂
// Qᵤ       Term in argument of constituent M₁
// N        Longitude of moon's node

namespace Congen {

  // The interface to libcongen makes use of valarrays whose lengths
  // and contents are prescribed, but not checkable at compile time.
  // Thus there is the risk that future changes to the interface could
  // result in older programs compiling OK but running incorrectly.
  // To prevent this, client programs should contain a preprocessor
  // check like the following:
  //   #if Congen_interfaceRevision != 0
  //   #error trying to compile with an incompatible version of libcongen
  //   #endif
  // The value will increment only if and when one of those risky
  // changes is made to the interface.

  #define Congen_interfaceRevision 0

  // Similarly, the next function can be used in autoconf
  // (configure.ac) scripts as follows to test that the library that
  // you are about to link with is the right version:
  //   AC_MSG_CHECKING([for libcongen (interfaceRevision_0)])
  //   LIBS="$LIBS -lcongen"
  //   AC_LINK_IFELSE(
  //    [AC_LANG_PROGRAM([[#include <Congen>]],
  //                     [[Congen::interfaceRevision_0();]])],
  //     AC_MSG_RESULT([yes]),
  //    [AC_MSG_RESULT([NO])
  //     AC_MSG_ERROR([either cannot find libcongen or found wrong version; try setting LDFLAGS.])
  //    ])
  // If invoked it does nothing.

  void interfaceRevision_0 ();

  // Where valarrays are used to contain coefficients of the following
  // terms of V and u, these are the indices to the respective
  // coefficients.

  // V portion of argument, evaluated at beginning of year.
  const uint_fast8_t T_index   = 0;
  const uint_fast8_t s_index   = 1;
  const uint_fast8_t h_index   = 2;
  const uint_fast8_t p_index   = 3;
  const uint_fast8_t p₁_index  = 4;
  const uint_fast8_t c_index   = 5;    // Constant angle (degrees).
  const uint_fast8_t numVterms = 6;

  // u portion of argument, evaluated at mid-year.
  const uint_fast8_t ξ_index   = 0;
  const uint_fast8_t ν_index   = 1;
  const uint_fast8_t ν′_index  = 2;
  const uint_fast8_t 2ν″_index = 3;
  const uint_fast8_t Q_index   = 4;
  const uint_fast8_t R_index   = 5;
  const uint_fast8_t Qᵤ_index  = 6;
  const uint_fast8_t numuterms = 7;

  // With the exception of "unity," for which we use 1, Congen and SP
  // 98 Table 2 identify node factor formulas by their formula numbers
  // in SP 98.  The following constants are optional syntactic sugar
  // that may at least clarify matters for those without access to SP
  // 98.

  const uint_fast8_t f_1   = 1;
  const uint_fast8_t f_Mm  = 73;
  const uint_fast8_t f_Mf  = 74;
  const uint_fast8_t f_O₁  = 75;
  const uint_fast8_t f_J₁  = 76;
  const uint_fast8_t f_OO₁ = 77;
  const uint_fast8_t f_M₂  = 78;
  const uint_fast8_t f_KJ₂ = 79;
  const uint_fast8_t f_M₁C = 144;  // A71 in SP 98.
  const uint_fast8_t f_M₃  = 149;
  const uint_fast8_t f_M₁  = 206;  // Unique U.S. definition.
  const uint_fast8_t f_L₂  = 215;
  const uint_fast8_t f_K₁  = 227;
  const uint_fast8_t f_K₂  = 235;

  // Compound constituents may be specified using coefficients of the
  // following popular constituents.

  const uint_fast8_t O₁_index = 0;
  const uint_fast8_t K₁_index = 1;
  const uint_fast8_t P₁_index = 2;
  const uint_fast8_t M₂_index = 3;
  const uint_fast8_t S₂_index = 4;
  const uint_fast8_t N₂_index = 5;
  const uint_fast8_t L₂_index = 6;
  const uint_fast8_t K₂_index = 7;
  const uint_fast8_t Q₁_index = 8;
  const uint_fast8_t ν₂_index = 9;
  const uint_fast8_t S₁_index = 10;
  const uint_fast8_t M₁_DUTCH_index = 11;
  const uint_fast8_t λ₂_index = 12;
  const uint_fast8_t numCompoundBases = 13;

  typedef uint16_t year_t;  // Range 1..4000

  // Satellites for Doodson-style constituents get specified with a
  // vector of Satellite structs.  Congen does not perform adjustments
  // for latitude-dependent satellites, so the client should either
  // apply the latitude adjustment to r before passing it to Congen or
  // omit those satellites entirely.

  // It appears to be traditional Doodson usage to work with the
  // negative of N instead of N itself.  Those deltas need to be
  // negated before passing to Congen.

  struct Satellite {
    double r;    // amplitude ratio vs. the main constituent
    double Δp;   // delta of coefficient of p vs. the main constituent
    double ΔN;   // delta of coefficient of N vs. the main constituent
    double Δp₁;  // delta of coefficient of p₁ vs. the main constituent
    double α;    // phase correction vs. the main constituent (degrees)
  };

  struct Constituent {

    // A Constituent is maintained using valarrays of equilibrium
    // arguments and node factors for the range of years that was
    // specified at the time of its construction.  Operations such as
    // adding two Constituents together are performed as vector
    // operations on those valarrays.  The client program must ensure
    // that every Constituent participating in such operations was
    // created using the same range of years; otherwise, garbage in,
    // garbage out.

    // libcongen will never normalize the (Vₒ+u) attribute of any
    // Constituent to [0, 360) or (-180, 180] degrees.  The helper
    // functions normalize, snormalize, and makeArrays supply
    // normalized results as needed for export.

    std::string name;
    double speed;                     // degrees per hour
    std::valarray<double> (Vₒ+u);     // degrees; [0] is firstYear
    std::valarray<double> f;          // [0] is firstYear

    // Default constructed constituents are only placeholders.  Speed
    // is initalized to zero; (Vₒ+u) and f are left in their default
    // initial states (zero length).  Name is set to "default".
    Constituent ();

    // This constructor is semantically equivalent to default
    // construction followed by resize(numYears).
    explicit Constituent (uint16_t numYears);

    // Copy constructor is semantically equivalent to default
    // construction followed by assignment.
    Constituent (const Constituent &x);

    // Constructor for Darwin-style constituents.

    // Coefficients for terms of V and u are passed in valarrays of
    // size 6 and 7, respectively.  See above for the ordering.

    // f_formula is the node factor formula number from SP 98; see above.

    // Speed is calculated as of the beginning of the year specified
    // by epochForSpeed.  For NOS compatibility, use 1900.

    Constituent (const std::string &name_in,
         const std::valarray<double> &V_coefficients,
         const std::valarray<double> &u_coefficients,
         uint_fast8_t f_formula,
         year_t firstYear,
         year_t lastYear,
                 year_t epochForSpeed);

    // Constructor for Doodson-style constituents.  A vector of
    // Satellites substitutes for the u coefficients and node factor
    // formula, but otherwise the operation is exactly the same as the
    // previous constructor.

    Constituent (const std::string &name_in,
         const std::valarray<double> &V_coefficients,
         const std::vector<Satellite> &satellites,
         year_t firstYear,
         year_t lastYear,
                 year_t epochForSpeed);

    // The other constructors and the operations on Constituent are
    // sufficient to enable clients to define base constituents and
    // compute compound constituents from them.  However, constructing
    // the same base constituents in every client is painful and
    // redundant.  This constructor allows compound constituents to be
    // specified in terms of the 13 "popular" constituents listed
    // above.  Their definitions are compiled in, so each of those 13
    // may be specified in lazy fashion using a coefficient of 1 for
    // itself.

    Constituent (const std::string &name_in,
         const std::valarray<double> &coefficients,
         year_t firstYear,
         year_t lastYear,
                 year_t epochForSpeed);

    // Assignment duplicates every field regardless of current state.
    Constituent &operator=  (const Constituent &x);

    // Add constituents together to produce a compound constituent.
    // The name is reset to "nameless".
    Constituent &operator+= (const Constituent &x);

    // Multiply by a scalar.
    // The name is reset to "nameless".
    Constituent &operator*= (double x);

    // Resize destroys any data currently stored in the Constituent.
    //   - (Vₒ+u) is set to the specified size and filled with zeroes.
    //   - f is set to the specified size and filled with ones.
    //   - speed is set to zero.
    //   - name is set to "zero".
    void resize (uint16_t numYears);

  };

  // Reminder to self:  The C++ argument-dependent name lookup rules
  // conveniently cause these operations to work without a Congen::
  // qualifier by virtue of the fact that a Constituent is involved.

  Constituent operator+ (const Constituent &x, const Constituent &y);
  Constituent operator* (double x, const Constituent &y);
  Constituent operator* (const Constituent &y, double x);

  // As a sanity check, generate tables from SP 98 and send to stdout.
  // Make sure your terminal is using a monospace font, UTF-8, and at
  // least 87 characters wide.  LANG=en_US.utf8 xterm -fn
  //   -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 &
  void tables();

  // ----- Helper functions -----

  // Normalize an angle to [0, 360) degrees, round to the specified
  // number of decimals (> 0, ≤ 20), and return as a string of length
  // decimals+4.  Halfway cases are rounded according to the
  // implementation-dependent behavior of the %f printf format, which
  // for GNU/Linux is the weird "nearest even number" rule.
  std::string normalize (double degrees, uint_fast8_t decimals);

  // Normalize an angle to (-180, 180] degrees, round to the specified
  // number of decimals (> 0, ≤ 20), and return as a string of length
  // decimals+5.  Halfway cases are rounded according to the
  // implementation-dependent behavior of the %f printf format, which
  // for GNU/Linux is the weird "nearest even number" rule.
  std::string snormalize (double degrees, uint_fast8_t decimals);

  // Parse the text format used for congen_input.txt in Congen 1.5 and
  // earlier and append any Constituents specified therein to
  // constituents.

  // A Darwin-style constituent is specified as a line of this form:
  //   name  Basic   T s h p p₁ c   ξ ν ν′ 2ν″ Q R   f_formula

  // A Doodson-style constituent begins with a line of this form:
  //   name  Doodson   T s h p p₁ c   #-satellites
  // followed by additional lines that specify the indicated number of
  // satellites, possibly more than one per line.  Each satellite has
  // the following form, which is identical to the format used in the
  // IOS tidal package's tide3.dat file:
  //       Δp -ΔN Δp₁ α r[RN]
  // (A capital letter 'R' and a digit are optionally suffixed to r.)
  // Please note:
  //   Consistent with IOS, ΔN is NEGATED.
  //   Consistent with IOS, α is specified in ROTATIONS, not degrees.
  //   Latitude-dependent satellites (those with RN) are IGNORED.

  // A compound constituent is specified as a line of this form:
  //   name  Compound   O₁ K₁ P₁ M₂ S₂ N₂ L₂ K₂ Q₁ ν₂ S₁ M₁-DUTCH λ₂
  // For compound constituents, trailing zeroes may be omitted.

  // Comment lines contain # in the first column.

  // Returns 0 if input parsed OK, line number containing error if not.

  unsigned parseLegacyInput (std::istream &is,
                 year_t firstYear,
                 year_t lastYear,
                 year_t epochForSpeed,
                 std::vector<Constituent> &constituents);

  // Convert a vector of Constituents into the plain C arrays that are
  // expected by libtcd's create_tide_db function.  It is the client's
  // responsibility to deallocate the memory using delete [] (or
  // choose not to).  Equilibrium arguments are normalized to [0.00,
  // 359.99] as required by libtcd.

  void makeArrays (const std::vector<Constituent> &constituents,
           char **&names,
           double *&speeds,
           float **&equilibriumArgs,
           float **&nodeFactors);

}

#endif

https://flaterco.com/xtide/files.html#experts


Congen README file

https://flaterco.com/xtide/files.html#experts

$Id: README 6742 2018-01-14 18:31:16Z flaterco $

    congen:  constituent generator.
    Copyright (C) 1997  David Flater.

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <http://www.gnu.org/licenses/>.

Preface
-------

This README is intended to be read using a monospace font and the UTF-8
character encoding.  One can launch a suitable xterm with the following
command:

LANG=en_US.utf8 xterm -fn -misc-fixed-medium-r-normal--20-200-75-75-c-100-iso10646-1 &

Overview
--------

This is the README file for the Congen package.  The Congen package contains
three distinct pieces, each of which is documented in more detail below:

1.  libcongen, a C++ library for generating the speeds, equilibrium
arguments, and node factors of tidal constituents.

2.  congen, a command-line program for generating the speeds, equilibrium
arguments, and node factors of tidal constituents using text files for input
and output.

3.  Additional scripts that are not normally needed but are useful for
troubleshooting.

THIS PACKAGE IS AVAILABLE FROM:
https://flaterco.com/xtide/files.html#experts

Prerequisites
-------------

If libtcd is properly installed, the congen program will automatically be
linked with it and enabled to generate a TCD file in lieu of its usual text
format output.  libtcd can be obtained from:
https://flaterco.com/xtide/files.html#libtcd

If libtcd is absent, the congen program will still compile but the -tcd
command line option will be disabled.

Installation
------------

Congen is packaged with GNU automake, so all usual GNU tricks should work.
Help on configuration options can be found in the INSTALL file or obtained by
entering ./configure --help.

Normally, one should only need to do the following to compile and install the
library and client program:

bash-3.1$ ./configure
bash-3.1$ make
bash-3.1$ su
bash-3.1# make install

However, in the event that libtcd is installed in a nonstandard location, an
invocation such as the following might be required:

bash-3.1$ ./configure CPPFLAGS="-I/usr/local/libtcd/include" \
                      LDFLAGS="-L/usr/local/libtcd/lib"
bash-3.1$ make

libcongen
---------

libcongen is a C++ library for generating the speeds, equilibrium arguments,
and node factors of Darwin-style tidal constituents more or less as defined
in SP 98:

   Manual of Harmonic Analysis and Prediction of Tides.  Special Publication
   No. 98, Revised (1940) Edition (reprinted 1958 with corrections;
   reprinted again 1994).  United States Government Printing Office, 1994.

Additionally, libcongen provides limited support for approximating
Doodson-style tidal constituents within the infrastructure of the former.
The Doodson approach is discussed in the following publication:

   Foreman, M.G.G., 1977.  Manual for Tidal Heights Analysis and Prediction.
   Pacific Marine Science Report 77-10, Institute of Ocean Sciences,
   Patricia Bay, Sidney, B.C. (2004 revision).

The Congen header file is intended to be self-documenting with regards to use
of the interface, assuming that one has access to SP 98 and a general
understanding of the subject matter.  Client programs should #include
<Congen> and link with -lcongen -lm.

congen
------

The congen program provides the functionality of libcongen using text files
for input and output.

Usage: congen [-b year] [-e year] [-a1|-a2] [-tcd filename] [-sp98test]
              < congen_input.txt > output.txt

Years may range from 1 to 4000, but the Gregorian calendar is assumed in all
cases.

-b year   Sets the first year for which to generate output.  Default 1970.

-e year   Sets the last year for which to generate output.  Default 2037.

-a1       Calibrate speeds of constituents for 1900-01-01.  This is the
          default and it is necessary for compatibility with US National
          Ocean Service (NOS) predictions.

-a2       Calibrate speeds of constituents for the beginning of the year that
          is midway between the first and last years.

-tcd filename  Instead of sending text format output to stdout, write the
               results as a TCD file.  Requires libtcd.

-sp98test   As a sanity check, generate tables from SP 98 and send to stdout.
            Make sure your terminal is using a monospace font, UTF-8, and at
            least 87 characters wide.

The format of the input file for the congen program is defined below.  Please
see the included file congen_input.txt for numerous examples.

                                - Terminology -

(Vₒ+u)   Constituent argument at beginning of a tidal series
f        Node factor

V        Principal portion of constituent argument
T        Hour angle of mean sun
s        Mean longitude of moon
h        Mean longitude of sun
p        Mean longitude of lunar perigee
p₁       Mean longitude of solar perigee

u        Part of constituent argument depending upon variations in obliquity of
         lunar orbit
ξ        Longitude in moon's orbit of lunar intersection
ν        Right ascension of lunar intersection
ν′       Term in argument of lunisolar constituent K₁
2ν″      Term in argument of lunisolar constituent K₂
Q        Term in argument of constituent M₁
R        Term in argument of constituent L₂
Qᵤ       Term in argument of constituent M₁
N        Longitude of moon's node

r    (For Doodson satellite) Amplitude ratio vs. the main constituent
α    (For Doodson satellite) Phase correction vs. the main constituent

                         - Darwin-style constituents -

A Darwin-style constituent is specified as a line of this form:
  name  Basic   T s h p p₁ c   ξ ν ν′ 2ν″ Q R   f_formula

c is a constant term specified in degrees.  The other lettered fields give
coefficients of the astronomical terms defined above.

With the exception of "unity," for which we use 1, Congen and SP 98 Table 2
identify node factor formulas by their formula numbers in SP 98.  Users of
libcongen have the benefit of symbolic constants defined in the Congen header
file, but in congen input you must supply the number.

  f_1   = 1;
  f_Mm  = 73;
  f_Mf  = 74;
  f_O₁  = 75;
  f_J₁  = 76;
  f_OO₁ = 77;
  f_M₂  = 78;
  f_KJ₂ = 79;
  f_M₁C = 144;  // A71 in SP 98.
  f_M₃  = 149;
  f_M₁  = 206;  // Unique U.S. definition.
  f_L₂  = 215;
  f_K₁  = 227;
  f_K₂  = 235;

                        - Doodson-style constituents -

A Doodson-style constituent begins with a line of this form:
  name  Doodson   T s h p p₁ c   #-satellites
followed by additional lines that specify the indicated number of satellites,
possibly more than one per line.

Each satellite has the following form, which is identical to the format used
in the original IOS tidal package's tide3.dat file:
      Δp -ΔN Δp₁ α r[RN]
(A capital letter 'R' and a digit are optionally suffixed to r.)

Please note:
  Consistent with IOS, ΔN is NEGATED.
  Consistent with IOS, α is specified in ROTATIONS, not degrees.
  Latitude-dependent satellites (those with RN) are IGNORED by congen.

Following is a complete example of a translation from IOS' tide3.dat.

Before:

      R2      2  2 -1  0  0 -1-0.50   2
      R2     0  0  2 .50 0.2535     0  1  2 .0  0.0141

After:

R2-IOS  Doodson   2 0 1 0 -1 180    2
             0  0  2 .50 0.2535     0  1  2 .0  0.0141

Note the differences in the V part of the record.  In Congen terms, the first
part of the record for each constituent in IOS' tide3.dat has the following
form:
   T  s+T  h-T  p  -N  p₁  -c (rotations)

To get T, s, h, p, p₁, c as expected by Congen,
  Given       T       s+T       h-T    p     -N    p₁     -c (rotations)
  Do this    same  subtract T  add T  same  skip  same  multiply by -360
  To get      T        s         h     p           p₁      c (degrees)

N has nowhere to go, but it is almost always zero.  The only exception in the
IHO constituent list is 3N2MS12 (L YZA YZZ).

                           - Compound constituents -

A compound constituent may be specified as a line of this form, providing
coefficients of the indicated constituents:
  name  Compound   O₁ K₁ P₁ M₂ S₂ N₂ L₂ K₂ Q₁ ν₂ S₁ M₁-DUTCH λ₂

Trailing zeroes may be omitted.

Congen uses compiled-in definitions of the indicated constituents to compute
the compound constituent, so each of the 13 may be specified in lazy fashion
using a coefficient of 1 for itself.

                                 - Comments -

Comment lines contain # in the first column.

Additional scripts
------------------

The program diff_congen_output compares two congen outputs, which are assumed
to have been generated from the same or comparable input, and reports on
discrepancies between them.  "Comparable input" means that the constituents
must have the same names, be in the same order, and have the same range of
years.

diff_congen_output ignores the following amount of error:
  speeds:                   0 degrees/hour
  equilibrium arguments:  .01 degree
  node factors:         .0001

This corresponds to rounding differences in the last significant digit of
equilibrium arguments and node factors and zero tolerance for differences in
speeds.

The script XDO2Basic.rb translates an Extended Doodson Number (XDO) as used
in "Standard list of tidal constituents" from the Tide, Water Level and
Current Working Group (TWCWG) of the IHO to the V part of a Congen Basic
constituent definition.  Both numeric and alphabetic forms are supported.

  bash-4.3$ XDO2Basic.rb ABZYZZA     # J1
  XX1  Basic  1 1 1 -1 0 -90

The script Compound2Basic.rb takes Congen format input and reduces all
Compound constituents to Basic format, to the extent possible.  It does not
handle node factors (it sets all of them to 1), and constituents with a
nonzero coefficient for M1-DUTCH are not correctly reducible (warnings are
placed in the output where applicable).

  bash-4.3$ ./Compound2Basic.rb
  2MK3  Compound  0 -1 0 2 0 0 0 0
  2MK3      Basic  3 -4 3 0 0 90      4 -4 1 0 0 0      1

UTF-8 sources
-------------

Some source files in this package, as well as this README, use the UTF-8
character encoding to accurately reproduce the Greek letters and so forth
that were used in the original formulæ.  However, compiling a program that
uses Unicode characters in identifiers is still difficult and not very
portable.  This distribution therefore uses a sed script to automatically
replace the Unicode characters in source files with plain text; λ becomes
lambda, Δ becomes DELTA, etc.

The source code as it was originally intended to look is in the utf8-src
subdirectory of the distribution.  For maximum readability, those wishing to
review the source code should read the sources in utf8-src rather than the
"mangled" versions that are built from them.

Supporting materials
--------------------

Related materials and government publications can be downloaded from
https://flaterco.com/xtide/files.html under the headings "For experts" and
"Miscellaneous government publications."

(End of README)

https://flaterco.com/xtide/files.html#experts


XTide downloads

Warning for Windows users

XTide was designed for Unix and X11, not Microsoft Windows. If you want to try to use it under Windows anyway, there's a precompiled binary for the command-line client, and there are also some ports. However, these are all supported by their respective maintainers. Please route support questions accordingly.

Contents

On 2018-03-23, the file hosting was migrated from ftp to https. For now, the files in https://flaterco.com/files/xtide/ are also available by anonymous FTP from ftp://ftp.flaterco.com/xtide/.

  • Harmonics files
  • libtcd
  • XTide
  • World Vector Shoreline data
  • Contrib packages and patches
  • Extras
  • For experts
  • Miscellaneous government publications

Harmonics files

If you are looking for data for countries other than the US, read this FAQ.

file | built with | works with | description
harmonics-dwf-20181227-free.tar.bz2 | libtcd 2.2.7-r2 | XTide 2.8+ | All data for the US and associated locales available from the National Ocean Service web site as of 2018-12-24. List of included locations
harmonics-dwf-20181227-SQL.tar.bz2 | PostgreSQL 11.1 | Harmbase2 | Dump of Harmbase2 database.

libtcd source code distribution

  • libtcd-2.2.7-r2.tar.bz2, prerequisite for XTide, tideEditor, tcd-utils, et al.
  • New libtcd documentation
  • Old libtcd documentation: Jan Depner, "Format for the Oceanographic and Atmospheric Master Library (OAML) Tide Constituent Database," rev. 2003-06-06
    • PDF format
    • OpenOffice format
    • Notes by DWF

XTide source code distribution

  • xtide-2.15.2.tar.bz2, the current stable release of XTide. Requires libtcd. You also need a harmonics file; see above.

It has become popular among app developers to derive works from the ancient final release of XTide version 1 because the C code of XTide 1 is simpler. Cosmetic issues aside, XTide 2 implements a better algorithm for estimating water levels at subordinate stations and correctly handles more of the unusual cases.

World Vector Shoreline data

World Vector Shoreline data for optional use with XTide 2.5 or newer. 37 MB.

These files were published on the National Geophysical Data Center (NGDC) 5-Minute Gridded Global Relief Data CD-ROM (ETOPO5), 1993, and are public domain. They are available from NOAA at http://www.ngdc.noaa.gov/mgg/global/relief/ETOPO5/BOUNDARY/WVS. Related information is available at http://www.ngdc.noaa.gov/mgg/fliers/93mgg01.html. If the files are obtained from NOAA, the filenames must be changed to all lowercase letters to work with XTide.

Contrib packages and patches

  • Enhanced documentation in .chm format (Microsoft Compiled HTML Help) by Kelly Bellis. Last rev 20170105 for XTide 2.15.1.
  • Binary packages:
    OS/Flavor | Info
    Linux/Fedora | XTide RPMs are available in Fedora's "everything" package collection (formerly Fedora Extras) courtesy of Mamoru Tasaka et al.
    Linux/Debian | Debian packages courtesy of Peter S. Galbraith. These are extremely out-of-date; you are better off to build from source and get the latest data.
    FreeBSD | FreeBSD package
    DOS | DOS binary for the command-line client (2.15) built with DJGPP. It is usable in a DOS box under any 32-bit version of Windows and in DOSBox under 64-bit Windows.
    Windows | Windows binary for the command-line client (2.15) built with Visual Studio Community 2015 with Update 1. It still has to run in a DOS box, but is compatible with Windows 10 64-bit.
    Android/ARM | Android (ARM) binaries for tide and xttpd (2.15) built with android-ndk-r10e. The targeted device was a Kindle Fire 1st Gen (arch armv7-a, tune cortex-a9, API level 9, hard floating point). They are runnable only on a rooted device and serve mainly as a proof of concept for libxtide on Android.
  • PirateLeft SlackBuild scripts by KaMii: libtcd, xtide (or you could RTFM)
  • Alternative XTide icons contributed by Kelly Bellis.
  • Alternative XTide icons contributed by Morten Kjeldgaard.
  • Telephone interface: From NerdVittles, a text-to-speech XTide bot for the Asterisk PBX (via PBX in a Flash) is available here or here.
  • WordPress tide prediction plugin by Mir Rodríguez.
  • Drupal tide prediction plugin by Jacob Lear. (Hosted on same site as the WordPress plugin.)
  • HTML PHP front end to generate an enhanced tide calendar with Hawaiian L10n using a customized pcal 4.11.0 and XTide 2.9.5, by Eric Nichols.
  • Joomla component (jtide) to import tide data from XTide, also by Eric Nichols, now maintained by David Limb.
  • GSHHS patch—test code to make XTide read Global Self-consistent Hierarchical High-resolution Shorelines instead of WVS files (DWF). This patch from an old development snapshot applies to 2.8.3 with little trouble, but is not maintained.

Extras

  • tideeditor-1.4.5.tar.xz, a GUI editor for Tide Constituent Database (TCD) files. Requires libtcd and Qt 4.x.
  • tcd-utils-20120115.tar.bz2, command-line tools for converting Tide Constituent Database (TCD) files to and from other formats. Requires libtcd.

For experts

Software:

  • congen-1.7.tar.xz. The Congen package includes libcongen, a C++ library for generating the speeds, equilibrium arguments, and node factors of tidal constituents, and congen, a command-line program for generating the speeds, equilibrium arguments, and node factors of tidal constituents using text files for input and output. This package requires a case-sensitive file system to build correctly.
    • README
    • libcongen header file
  • harmgen-3.1.3.tar.xz, program to derive harmonic constants from water level observations. Requires Congen and Octave.
    • Help on installing Octave is available here. As tested on 2018-01-15, Harmgen 3.1.2 worked with Octave 4.2.1.
    • README
    • harmgen-extras-20080523.tar.bz2, obsolete data converters and stuff.
  • harmbase2-20181227.tar.xz, harmonic constant management system. Requires PostgreSQL 11.1, Congen, libtcd and libdstr.

Other materials:

  • seasonal_corrections.xls, a spreadsheet for approximating Sa and Ssa from Admiralty-style seasonal corrections. Contributed by Art Najjar of NAVO.
  • NAVO.xls, spreadsheet of constituent definitions contributed by Art Najjar of NAVO.
  • congen_input.txt, input file for congen. Last update 2018-01-14.

See also the IHO list of constituents in the next section.

Miscellaneous government publications

IHO list of constituents, downloaded from http://www.iho.shom.fr/COMMITTEES/TC/Constituents.pdf on 2004-08-13 and 2006-08-25, and from https://www.iho.int/mtg_docs/com_wg/IHOTC/IHOTC_Misc/TWCWG_Constituent_list.pdf on 2018-01-01.

  • 2017-05-08 version
  • 2006 version
  • 2003 version

Link: NOS popular publications page

Manual of Harmonic Analysis and Prediction of Tides. Special Publication No. 98, Revised (1940) Edition (reprinted 1958 with corrections; reprinted again 1994). United States Government Printing Office, 1994. Downloaded from NOAA Central Library via NOAA's Historical Map & Chart Collection, 2015-04-27.

Computer Applications to Tides in the National Ocean Survey. Supplement to Manual of Harmonic Analysis and Prediction of Tides (Special Publication No. 98). National Ocean Service, National Oceanic and Atmospheric Administration, U.S. Department of Commerce, January 1982. Downloaded from NOS, 2016-12-18.

Tide and Current Glossary. National Ocean Service, January 2000. Downloaded from NOS, 2003-12-19.

Tidal Datums and their Applications. NOAA Special Publication NOS CO-OPS 1, June 2000. Downloaded from NOS, 2004-08-27.

Computational Techniques for Tidal Datums Handbook. NOAA Special Publication NOS CO-OPS 2, September 2003. Downloaded from NOS, 2007-03-01.

Tidal Analysis and Prediction. NOAA Special Publication NOS CO-OPS 3, July 2007. Downloaded from NOS, 2014-12-28.

Nathaniel Bowditch, LL.D. The American Practical Navigator: An Epitome of Navigation. NIMA Pub. No. 9, Bicentennial Edition, 2002. Downloaded from NGA, 2004-09-28. 42 MB. Chapter 9 is a tutorial on tides and currents.

Home


# $Id: harmonics_boilerplate.txt 4391 2012-03-03 00:15:50Z flaterco $
#
# Definitions and constants for XTide
#
# NOTE:  This file should not be used as-is to provide a constituent
# set to harmgen because it contains multiple constituents with the
# same frequency.  A better constituent set is included in the harmgen
# distribution (see the README).
#
#
# ********* NOT FOR NAVIGATION ********
#
# *** DO NOT RELY ON THIS DATA FILE FOR DECISIONS THAT CAN RESULT IN ***
# ***                   HARM TO ANYONE OR ANYTHING.                  ***
#
# Highly trustworthy tide predictions cannot be achieved on a zero
# budget.  If you need guaranteed results, don't use these data!
# Contact the tide authority for your region (NOAA in the U.S.).
#
# This data file is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without any warranty that its use will NOT
# INFRINGE ANY RIGHTS, and without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
#
# WHOEVER CHOOSES TO REDISTRIBUTE THESE DATA ASSUMES ALL LIABILITY
# ASSOCIATED THEREWITH.  NEITHER DAVID FLATER NOR ANYONE ELSE INVOLVED
# SHALL BE LIABLE PERSONALLY OR OTHERWISE FOR ANY LOSSES THAT THE
# REDISTRIBUTOR MIGHT SUFFER AS A CONSEQUENCE OF ANY CLAIMS, BOGUS OR
# OTHERWISE, THAT ARE MADE TO THESE DATA.
#
#
# --- Notes to contributors ---
#
# After getting legal threats from the U.K. Hydrographic Office, I am
# no longer willing to accept any data without an explicit statement
# from the copyright owner or eminent authority either granting
# permission for non-commercial use with XTide or explaining that such
# permission is not required.  The absence of a copyright notice is
# not sufficient; however, a blanket permission for non-commercial use
# is sufficient.
#
# For more technical reasons, I am not prepared to accept data under
# conditions that require me to track uses of the data, to limit the
# uses of the data to a particular time period, or to verify that
# every user has read the legalese.  XTide has many different
# interfaces by which users can obtain results, and such requirements
# are impossible to implement in a reasonable and consistent fashion
# across all interfaces.  For a reasonable compromise, see what was
# done for the POL data:  a reference to legalese is included in the
# location name field.
#
#
# --- Copyright statements ---
#
# United States:  Data published by the U.S. government is by law
# non-proprietary.  Stations in the U.S., territories of the U.S.,
# commonwealths associated with the U.S., and countries with a Compact
# of Free Association with the U.S. have been included.  A few other
# stations available from the NOS web site have been dropped.
#
#   Notice available on the NOS web site at
#   http://tidesandcurrents.noaa.gov/disclaimers.html as of
#   2007-05-30:
#
#   The information on government servers are in the public domain,
#   unless specifically annotated otherwise, and may be used freely by
#   the public. Before using information obtained from this server,
#   special attention should be given to the date and time of the data
#   and products being displayed. This information shall not be
#   modified in content and then presented as official government
#   material.
#
#   The user assumes the entire risk related to its use of these
#   data. NOS is providing these data "as is," and NOS disclaims any
#   and all warranties, whether express or implied, including (without
#   limitation) any implied warranties of merchantability or fitness
#   for a particular purpose. In no event will NOS be liable to you or
#   to any third party for any direct, indirect, incidental,
#   consequential, special or exemplary damages or lost profit
#   resulting from any use or misuse of this data.
#
#   NOS requests that attribution be given whenever NOS material is
#   reproduced and re-disseminated. Pursuant to 17 U.S.C. 403, third
#   parties producing copyrighted (compilation) works consisting
#   predominantly of material created by Federal Government employees
#   are encouraged to provide notice with such work(s) identifying the
#   U.S. Government material incorporated and stating that such
#   material is not subject to copyright protection.
#
# Canada:  The harmonic constants used to perform tide predictions for
# locations in Canada are derived from sea level data made available
# by Marine Environmental Data Services, Fisheries and Oceans Canada,
# for public, non-commercial use.  The predictions are not the same as
# those computed by the Canadian Hydrographic Service, which uses its
# own sets of harmonic constants.
#
#   Copyright notice for the sea level data at
#   http://www.dfo-mpo.gc.ca/notices-avis-eng.htm (rev. 2009-07-17):
#
#   Non-Commercial Reproduction
#
#   Information on this site, other than government symbols, has been posted
#   with the intent that it be readily available for personal and public
#   non-commercial use and may be reproduced, in part or in whole and by any
#   means, without charge or further permission from Fisheries and Oceans
#   Canada, provided that:
#
#   * due diligence is exercised in ensuring the accuracy of the information
#     reproduced;
#   * Fisheries and Oceans Canada is identified as the source department; and
#   * the reproduction is not represented as an official version of the
#     information reproduced, nor as having been made in affiliation with, or
#     with the endorsement of, Fisheries and Oceans Canada.
#
# Netherlands:  The Netherlands data was contributed directly by Koos
# Doekes of the Rijkswaterstaat RIKZ/ZDI, who grants permission by his
# own authority:
#
#         Herewith I grant permission for non-commercial use
#         of all harmonic constants for the Netherlands by
#         users of Xtide or Xtide-based products.
#
#         This covers the use of the constants for Dutch
#         ports in the Xtide-database by designers
#         of web applications, and the use in commercial
#         tidal prediction software in which the constants
#         themselves are not stored - i.e. the user has
#         to copy them from the Xtide-database himself.
#
#         It does NOT cover the use in commercial software
#         in which the constants are incorporated, which is
#         considered commercial use of the constants here.
#         Any request for permission of use of Dutch constants
#         in software of this kind should be redirected to
#         RIKZ.
#
# Germany:  The Germany data was contributed directly by Wolfgang
# Lange of the Bundesamt fuer Seeschifffahrt und Hydrographie (BSH),
# who grants permission by his own authority:
#
#         As long as you make your software using these tidal data
#         freely available, I grant permission for non-commercial use
#         of the harmonic constants for the 12 reference stations at
#         the german North Sea coast on the same conditions and rules
#         layed down in the letter from Koos Doekes, RIKZ/ZDI,
#         concerning the Netherlands harmonic constituents.
#
# UK:  Received 2003-11-15 DWF.  See also http://www.flaterco.com/pol.html.
#
#                                         Proudman Oceanographic Laboratory
#                                         Natural Environment Research Council
#
#                                         Bidston Observatory
#                                         Bidston Hill
#                                         Prenton
#                                         Merseyside
#                                         CH43 7RA
#                                         United Kingdom
# David Flater
# 13320 Country Ridge Drive               Tel +44 (0) 151 653 8633
# Germantown, MD  20874                   Fax +44 (0) 151 653 6269
# United States of America                www.pol.ac.uk
#
#
#                                         07 November 2003
#
# Dear David,
#
# This letter is to confirm that we are happy for you to download the
# sea level data from the British Oceanographic Data Centre website and
# use this in the generation of harmonic constants using the HarmGen
# software.  However there are a couple of things that we would politely
# ask that you do.
#
# 1.  Limit the number of harmonic constants you use in the software to
# a maximum of 40 for any port.  This should easily be enough to create
# very accurate tidal predictions as for nearly all locations, any
# harmonics left out (i.e. the 41st most significant constants onwards)
# will have amplitudes of the order of a centimetre.
#
# 2.  State that the data is derived from sea level data obtained from
# the British Oceanographic Data Centre based at the Proudman
# Oceanographic Laboratory, Liverpool.
#
# 3.  Make it clear that the predictions however are not the same as
# those computed by the Proudman Oceanographic Laboratory which uses its
# own sets of harmonic constants.
#
# 4.  Continue to make your software using the data freely available.
# Please inform us if you intend to produce a software product that you
# will be making a charge for.
#
# I hope these conditions are acceptable to you and it will be good to
# see the UK back on the map.
#
# Yours sincerely,
# Colin Bell
# Head of Applications Group
#
#
# Changelog
# ---------
#
# 2012-03-02  End of maintenance for non-free data
#
# As a result of the combination of lack of time, commercialism, and abuses,
# I have decided to officially end maintenance of the non-U.S. data, which
# were subject to a non-commercial-use-only license.  This will be the final
# entry in the changelog in the monolithic, legacy formatted
# harmonics_boilerplate.txt file.  Future updates will be logged more legibly
# in a new ChangeLog file bundled with the public domain data.
#
#
# 2011-12-30
#
# Imported NOS data from snapshot 2011-12-11.  Subordinate tide stations came
# from the new web site; subordinate currents have not yet been migrated, so
# the old process was used for them.
#
# A small percentage of subordinate station links were broken at the time of
# the snapshot, so a few stations will be down for the year.  Most subordinate
# tide stations that had complications attached to them disappeared in the
# migration to the new web site and are probably gone for good.  The new web
# site does not [yet] serve up station notes, as far as I can tell.
#
# The following four current reference stations stopped matching NOS
# predictions and were dropped along with their subs:
#
#   Throgs Neck, 0.3 n.mi. NE of, Long Island Sound, New York Current (15d)
#   The Race, 0.6 n.mi. NW of Valiant Rock, New York Current (38d)
#   North Inian Pass, Cross Sound, Alaska Current
#   Unimak Pass (off Scotch Cap), Alaska Current
#
# The meridian adjustment for College Pt was retained to make predictions agree
# with 2012 sub station 8517276.  Riverdale was fixed upstream (agrees with
# 2012 sub station 8518905).  NOS predictions for Fortescue Creek and Texaco
# Dock were unavailable for comparison, so they were again adjusted to agree
# with their 2008 results.
#
# The following two stations shifted *west* by 7 hours (i.e., a meridian of
# +7 is needed to make the new data match the 2010 predictions):
#   9465234  Hagemeister Island (north end), Alaska
#   9465249  Estus Point, Hagemeister Strait, Alaska
# NOAA predictions were unavailable for comparison; assumed OK.
#
#
# 2011-04-10
#
# Imported up-to-date NOS harmonic constants for Wrangell Narrows Current
# contributed by Mitch Cline via Dean Pentcheff.  Reran import of subordinate
# stations from December's web scrape to include all of the inside passage
# currents that depend on Wrangell Narrows.
#
#
# 2010-12-30
#
# Imported NOS data from snapshot 2010-12-19.
#
# Compared data with 20081201 snapshot to find recently broken meridians.
# Albany was fixed.  Santa Cruz, Coyote Pt. Marina, and Moss Landing went
# away.  Adjusted meridians of the following to agree with 20081201 results:
#   College Pt, Ft. of 110th Street, Long Island, New York
#   Riverdale, Hudson River, New York
#   Fortescue Creek, New Jersey
#   Texaco Dock, Hackberry Bay, Louisiana
#
# Fixed miscellaneous spelling errors and nits.
#
#
# 2010-05-29
#
# Mark Randolph checked the rest of California and found one other station
# that broke after December 2008 in the same manner as Santa Cruz:  General
# Fish Company Pier, Moss Landing, California.  Fixed that and thanks again
# to Mr. Randolph.
#
#
# 2010-05-22
#
# Santa Cruz, Monterey Bay, California now has the same problem as Albany and
# Coyote Point Marina (supposedly UTC data were LST).  It broke between
# December 2008 and December 2009.  Thanks to Mark Randolph for reporting the
# problem.
#
#
# 2009-12-27
#
# Due to significant, uncorrectable differences with authoritative
# predictions, the data for Germany were retired.
#
# Imported NOS data from snapshot 2009-12-22.
#
# Removed the current reference station Akutan Pass which no longer matches
# published tables (maximum velocities have decreased).
#
# Reapplied the meridian fixes for Albany and Coyote Point Marina.  The
# discrepancy for Albany versus the tide tables is now being reproduced by
# the new NOAA tide predictor.
#
# The LST harmonic constants for Johnston Atoll and Kwajalein changed
# meridians this year.  XTide does not use the LST constants, but there might
# be some impact on agreement with NOAA predictions for the subordinate
# stations that use those reference stations.
#
#
# 2008-12-28
#
# Imported NOS data from snapshot 2008-12-01.
#
# Reapplied the meridian fixes for Albany and Coyote Point Marina.
# Corrected latitude of Monte Carlo Island, AK.
# Fixed spelling of Monterey and Chapoquoit.
#
# In light of the continued absence of harmonic constants for currents on
# the NOS web site, I have reinstated 32 reference stations from CURCON00.US
# that still match NOS' published 2009 predictions, together with applicable
# subordinate stations from the 2008-12-01 web scrape.  As always, there is
# plenty of opportunity for improvement in the station names.  States were
# determined heuristically and some will be wrong.
#
# The database now includes a state field that provides the 2-letter USPS
# abbreviation for the state in which each tide station is located, when
# applicable.
#
# All TCD files and dumps are now being distributed in tarballs together
# with the boilerplate.
#
#
# 2007-12-28
#
# Imported NOS data from snapshot 2007-12-17.
#
# Reapplied the meridian fixes for Albany and Coyote Point Marina.
# Coordinates of I-526 bridge were fixed upstream.
#
# A comparison of all reference stations versus the 2008 tide tables
# published on the web revealed discrepancies for Anchorage, AK and Port
# O'Connor, TX.  The Anchorage discrepancies are small enough to be
# explained by a data update; however, the Port O'Connor discrepancies are
# major and are not helped by the meridian fix that worked for Albany and
# Coyote Point Marina.  Local observations are required to determine whether
# the Port O'Connor predictions are any good at all.  This is complicated by
# the fact that it is a diurnal station with small tidal range, making
# eyewitness confirmation that much more unreliable.  Subordinate stations
# depending on these reference stations will also fail to match the
# published tables.
#
#
# 2007-11-22
#
# To facilitate compliance with Linux distribution packaging policies
# and to draw more attention to the acceptable use restriction on
# non-U.S. data, the "free" and "nonfree" data are now being exported
# to separate TCD files.  At this time, all "free" data are public
# domain and all "nonfree" data are merely restricted to
# non-commercial use only.
#
# Replaced the data set for Harwich, England with one calculated from
# a longer time series.  Proudman still does not yet publish
# predictions for this location.
#
#
# 2007-03-18
#
# Updated approximated MLLW datums with improved estimates.
#
# Put IGNORE HEIGHTS in the legalese fields of the 14 subordinate
# stations where NOS zeroed out the heights.
#
#
# 2007-02-22
#
# Applied renamings as updated and improved by Walt Bilofsky (thanks
# Walt).
#
#
# 2007-02-11
#
# Interim release, without renamings.
#
# Imported NOS data from snapshot 2007-02-07.
#
# (9414449) Coyote Point Marina, San Francisco Bay, CA:  corrected meridian.
#           (Data claimed UTC, was UTC-8)
# (8518995) Albany, Hudson River, NY:  corrected meridian.
#           (Data claimed UTC, was UTC-5)
# I-526 bridge, Ashley River, South Carolina:  fixed longitude.
# Pascagoula, Mississippi Sound, Mississippi latitude was fixed upstream.
#
# In progress:  renamings.
#
# Since there were two reference stations with incorrect meridians
# (one that was reported last time and one that was just discovered),
# it is reasonable to expect that there will be more.
#
#
# 2006-07-08
#
# Coyote Point Marina, San Francisco Bay, California:  corrected meridian.
# Delaware City, Delaware River, Delweare:  fixed typo in name.
# Pascagoula, Mississippi Sound, Mississippi:  fixed latitude.
# I-526 bridge, Ashley River, South Carolina:  fixed longitude.
#
#
# 2006-03-05
#
# Installed renamings from AH for the 102 stations that lacked states.
#
#
# 2006-02-05
#
# Refreshed U.S. data from NOS web site (snapshot 2006-01-04).  AH has
# dealt with new and modified station names to maintain the naming
# convention installed 2005-11-27.  Still to be fixed is a list of
# stations that do not include their state in their name.  Most or all
# of those have been that way since November.  They didn't stick out
# much until an unrelated Harmbase query happened to group them
# together.
#
# An e-mail exchange with Todd Ehret of NOS CO-OPS this time led me to
# believe that the UTC constants for the Alaskan reference stations
# with weird time zones should be correct, so I have retained them.  A
# survey of affected subordinate stations shows that most should be
# correct if their reference station is correct (they all use the same
# one).  Most doubtful are the six subordinate stations on
# St. Lawrence Island.  I do not even have reliable intelligence on
# what the de facto time zone of St. Lawrence Island is.  It was not
# mentioned in the statute that defines U.S. time zones.
#
#
# 2005-11-27
#
# Installed renamings from August Hahn to achieve something like the
# naming convention previously followed in legacy data.  These
# renamings will be maintained through subsequent updates if the churn
# is not too bad.
#
#
# 2005-09-05
#
# Generated and installed harmonic constants for 49 Canadian stations
# using up to 10 years of hourly data (the maximum permitted download)
# from Marine Environmental Data Services (MEDS), Fisheries and Oceans
# Canada.
#
# MEDS publishes water level data for 962 stations.  Of those, only 92
# are currently active.  Of those 92, 43 are non-tidal, being located
# on or near the great lakes.
#
#
# 2005-06-05
#
# Generated and installed fresh harmonic constants for U.K. stations
# using all available data for the 19 year epoch from 1986 to 2004.
# Quality assurance information is available at
# ftp://ftp.flaterco.com/xtide/harmonics-dwf-2005-06-05-QA.txt
#
# Station Harwich, England is new with only 8 months of data.
# Authoritative predictions for this station are not yet available for
# comparison.
#
#
# 2005-01-20
#
# Deleted the following Alaskan reference stations, which were
# rendered incorrect by technical difficulties confirmed by Todd Ehret
# of NOS CO-OPS, and all dependent sub stations.  They may return
# corrected in future revisions.
#
#  - 9460150 Attu, Massacre Bay
#  - 9465261 Clarks Point, Nushagak Bay
#  - 9468132 St. Michael, Norton Sound
#  - 9497649 Prudhoe Bay #2
#  - 9497778 Cross Island
#
# Also deleted the following station which is listed as superseded.
#
#  - 9497652 Prudhoe Bay, Dock #1
#
#
# 2004-12-10
#
# Refreshed all NOS data from NOS web site.
#
#
# 2004-10-18
#
# No data changes -- just resyncing and renaming all the different
# editions of the database.
#   harmonics-dwf-2004-10-18-v2.tcd   Built with libtcd 2.0
#   harmonics-dwf-2004-10-18-v1.tcd   Built with libtcd 1.100
#   harmonics-dwf-2004-10-18.sql      Postgres 7.4.2
#   harmonics-dwf-2004-10-18-dump     txt/xml restored from -v2.tcd
#   harmonics-dwf-2004-10-18-compat   txt/xml years 1970-2037 only
#
#
# 2004-10-08 DWF
#
# Updated RIKZ/MII references to new name, RIKZ/ZDI.
#
#
# 2004-10-05 DWF
#
# Rebuilt using libtcd 1.99, which corrects a problem where
# constituents with zero phases were being dropped.  The affected
# reference stations are Delfzijl, Netherlands; The Battery, New York
# Harbor, NY; and South Pass, LA.
#
#
# 2004-09-14 DWF
#
# Imported subordinate stations available from the NOS web site as of
# 2004-09-09.  Compare against
# http://co-ops.nos.noaa.gov/tide_pred.html.  Some stations will
# disagree moderately because the reference stations were updated and
# don't match the published tables.
#
# The smattering of sub stations in non-U.S. territory was suppressed.
#
# There are time zone problems in Alaska.  The LST used by the NOS for
# stations in Alaska does not always match the local statutory time
# zone (which I have followed).  For reference stations, the problem
# was detectable and correctable because the constants were available
# calibrated with UTC as well as LST.  But for the sub stations, it is
# impossible to tell whether a disagreement with NOS predictions
# results from a disagreement about time zone, incorrect calibration,
# or both.
#
# A few names suffixed by (A) and (B) reflect sub stations on the NOS
# web site with the same names and close coordinates, where it is far
# from obvious why there are two of them.  Other name clashes were
# resolved by disambiguation.
#
# (Nit) Corrected months_on_station for German ref stations from 13 to
# 12.  (It's a time zone / rounding issue, on list to be fixed.)
#
#
# 2004-09-07c DWF
#
# Put the following three stations on Eastern time (they were calibrated
# to Central time on the NOS web site):
#   Johns Island, Chassahowitzka Bay, FL
#   Chassahowitzka River, FL
#   Crystal River, Kings Bay, FL
#
#
# 2004-09-07b DWF
#
# Corrected heuristic for Alaskan time zones.  A few stations in the
# Aleutians were affected.
#
#
# 2004-09-07 DWF
#
# Added notes for stations in Alaska where the LST used by NOS does not
# match the apparent statutory time zone.  Presently these notes just
# get attached to the comments field in the TCD file, but the next major
# revision to the TCD format should enable XTide to display them more
# prominently.
#
#
# 2004-09-01 DWF
#
# Most reference stations available from the NOS web site as of
# 2004-08-26 have been imported.  Compare against
# http://co-ops.nos.noaa.gov/tide_pred.html.
#
# MLLW benchmarks were not available for all stations.  For stations
# where a MLLW datum was not available, the datum has been set to LAT.
#
# I know there are typos in the location names.
#
# Currents are not available at this time.  According to Mr. Ehret, they
# will become available when the new CO-OPS currents database is
# complete.
#
# The following stations, which are located in jurisdictions that are
# neither territories of the U.S., nor commonwealths associated with the
# U.S., nor countries with a Compact of Free Association with the U.S.,
# have been dropped.  Their data are distributed without legalese from
# the NOS web site; however, that does not necessarily mean that anyone
# other than the NOS has permission from the respective governments to
# use or redistribute the data.  This may seem paranoid, but the
# situation with the U.K. data that were pulled in 2001 was very
# similar.
#
#   Apia, Samoa
#   Bermuda Esso Pier, St. Georges Island, Bermuda
#   Fare Ute Point, Papeete Harbor, French Polynesia
#   La Unión, El Salvador
#   Madero, Tampico Harbor, Tamaulipas, Mexico
#   Puerto Corinto, Nicaragua
#   Puerto Cortés, Honduras
#   Puerto Quetzal (San Jose), Guatemala
#   Settlement Point, Grand Bahama I., Bahamas
#   Suva Harbor, Suva, Fiji
#
#
# 2004-08-19 DWF
#
# This is an interim release as I am starting over from scratch using
# Harmbase2.  All legacy data have been dumped.
#
# All U.S. data are temporarily down; the 2004-08-09 version of this
# file remains usable for those.  Mr. Ehret has indicated that there
# would be fees involved in obtaining harmonic constants and offsets
# in the format previously received, so I am abandoning all that and
# gearing up to scrape data off of the web.  According to Mr. Ehret,
# the set of locations on the web site is a superset of those used in
# published prediction tables.  The discrepancies that occur are
# because the harmonic constants on the web are updated continuously
# while the harmonic constants used for the published tables are fixed
# in advance.  Thus there seems little to be lost by replacing all of
# the legacy data with a snapshot of the web data.
#
# Data presently included:
#
# Netherlands reference stations computed from hourly levels 1999
# through 2002, as received from Koos Doekes on 2004-02-03.  Compare
# against http://www.getij.nl/engels/.
#
# German reference stations computed using Harmgen from year 2001
# observations sent by Wolfgang Lange on 2004-08-19.  The datums are
# adjusted to LAT.  Compare against
# http://www.bsh.de/en/Marine%20data/Forecasts/Tides/index.jsp.  (The
# web site is still using the MLWS datum, so the heights will disagree
# strongly until the web site is updated.  However, even adjusting for
# that, the agreement is not as good as could be hoped.  The BSH
# predictions are made using a non-harmonic method, so some
# discrepancies are inevitable.)
#
# German subordinate stations as sent by Wolfgang Lange on 2004-08-10.
#
# U.K. reference stations computed using Harmgen from at least four
# years of observations ending 2002-12-31, as downloaded from the BODC
# web site 2003-11.  Compare against http://www.pol.ac.uk/ntslf/tides/.
#
#
# 2004-08-09 DWF
#
# harmonics-dwf is a new database that emphasizes responsiveness to
# updates and traceability to authoritative sources instead of maximum
# coverage of locations and historical predictions.  All data known to
# be old and expired and all data for which no source of updates
# exists have been purged.  This will orphan many users who have been
# getting good results from old data.  For these, please continue to
# use RMK's database.
#
# harmonics-dwf now contains:
#   - U.S. reference stations provided by Todd Ehret of NOAA circa
#     2004-02-04.
#   - Netherlands reference stations provided by Koos Doekes of the
#     Rijkswaterstaat RIKZ/ZDI (then RIKZ/MII) on 2004-02-03.
#   - U.K. reference stations derived by Harmgen from BODC data,
#     2003-11.
#   - The most recent data for other U.S. reference stations that
#     were in RMK data rev. 2004-04-16 23:30 but not included in
#     the distribution from Todd Ehret.
#
# All sub stations are gone temporarily while I update my software to
# import the sub station data sent by Todd Ehret in February.  I will
# also be contacting Mr. Ehret to see if I can obtain a complete dump
# of all stations in current use so that I can build a legacy-free
# database.


XTide: Harmonic tide clock and tide predictor

San Francisco graph

Preface

Welcome to the verbose documentation for XTide 2. If you are reading this as a text file, please be aware that the text was extracted from the illustrated HTML version of the documentation that resides at https://flaterco.com/xtide/. The web version may also be more up-to-date than what you are reading.

THE XTIDE SOFTWARE DISTRIBUTION IS AVAILABLE FROM: https://flaterco.com/xtide/files.html

Buoy in the mist

Contents

  • License and disclaimer ("NOT FOR NAVIGATION," "ABSOLUTELY NO WARRANTY")
  • Verbose documentation
    • Introduction
    • System requirements
    • Installation instructions for supported platforms
    • Available ports for unsupported platforms
    • Modes and formats
    • Using the interactive interface
    • Advanced usage
    • Using the command line interface
    • Running the web server
    • Customizing XTide
    • What to do if your location isn't listed
    • Quirks, limitations, and bugs
    • FAQ
    • Design notes
    • Credits
    • Bibliography
    • Appendix A — Historical predictions and Y2038 compliance
    • Appendix B — Application of offsets for Min Flood and Min Ebb events
    • Appendix C — Making calendars fit onto a single page
  • Short attention span documentation for experienced XTide users
    • Differences from XTide 1
    • Quick install instructions
    • Change log
    • News (current XTide developments)

The XTide software distribution resides at https://flaterco.com/xtide/files.html.

Hint: If you have no idea what all this is about, try reading the FAQ first.

— David Flater (dave@flaterco.com)


Tide Constituent Database

Comments on this documentation should be returned to David Flater.

Contents

  1. Introduction
  2. Compiling libtcd
  3. Tide record (version 2.2)
  4. Public database header (version 2.2)
  5. libtcd 2.2.7 API
  6. V1 to V2 migration guide
  7. Changelog
  8. References

1. Introduction

libtcd provides a software API for reading and writing Tide Constituent Database (TCD) files.

The TCD file format and schema are used by XTide to retrieve constituent definitions (speeds, equilibrium arguments, and node factors), harmonic constants, subordinate station offsets and associated metadata for use in generating tide predictions.

The TCD file format and schema were originally designed by Jan Depner to improve the performance of XTide and to meet additional requirements of the U.S. Naval Oceanographic Office (NAVO). They are now maintained primarily by David Flater.

The design goals for TCD included:

  • Available without installing heavy external packages.
  • Efficient for indexing and loading of stations.
  • Compact file format.
  • Translatable without loss from legacy XTide .txt and .xml files.
  • Exportable to legacy .txt and .xml formats.
  • Modifiable by end user using tideEditor.
  • Able to detect tampering (usually, misguided attempts to edit the database in a word processor).

The TCD file format and schema and libtcd are in the public domain. They are distributed in the hope that they will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

For additional background, see Jan Depner, "Format for the Oceanographic and Atmospheric Master Library (OAML) Tide Constituent Database," rev. 2003-06-06.

2. Compiling and installing libtcd

Unix or Cygwin

The normal route:

bash-3.1$ ./configure
bash-3.1$ make
bash-3.1$ su
bash-3.1# make install

libtcd is packaged with the popular and portable GNU automake, so all usual GNU tricks should work. Help on configuration options can be found in the INSTALL file or obtained by entering ./configure --help.

Android

libtcd can be cross-compiled for Android using the NDK. An example script that builds libtcd (among other things) for Android on x86 or x86_64 Linux is in the current XTide distribution as scripts/Android/build.sh.

DOS + DJGPP

[Validated on DJGPP 2.05 with Long File Name (LFN) support.]

Just make -f DOS\Makefile.dj2.

Windows + Visual Studio

[Validated on Visual Studio Community 2015 with Update 1 under Windows 10 64-bit.]

  1. Do [Windows Logo Thingy Formerly Known as Start Menu] → All Apps → Visual Studio 2015 (folder) → VS2015 x64 Native Tools Command Prompt. To prevent inexplicable file system permissions problems, right click it and run as Administrator. (Ha ha... That was a little Windows in-joke. Now that we have UAC, the only way to prevent inexplicable file system permissions problems is to use a FAT32 file system.)
  2. VS\build.bat.

N.B., If Cygwin is installed, it is possible to run the original configure script and GNU make to build with Visual Studio. Refer to VS\README.txt for details.

3. Tide record (version 2.2)

This section documents the tide record schema of the Tide Constituent Database as it stands in libtcd version 2.2.

Fields designated as "header" fields are retrieved at indexing time and stored in memory for quick access. The rest are retrieved only when individual tide stations are loaded.

Type 1 records are for reference stations; type 2 records are for subordinate stations. Some fields are only encoded for one record type while others are encoded for both.

intX means signed X-bit integer. uintX means unsigned X-bit integer. TCD files are encoded with a bit-packing function that allows odd-sized fields to be stored efficiently. int varying and uint varying indicate fields whose lengths in bits are dynamically configured for each TCD file.

Floating-point numbers are encoded in the TCD file using scaled integers. An integer with a scale of X represents the real number obtained by dividing the integer by X.

Please note: All character strings stored in a TCD file use the character set ISO-8859-1.

Record type | TIDE_RECORD field | TIDE_RECORD data type | File encoding | Encodable range | Semantics
all | header.record_number | int32 | none | N/A | Records in TCD file are implicitly numbered [0, N-1].
all | header.record_size | uint32 | uint16 | [0, 65535] | Length of encoded record in bytes.
all | header.record_type | uint8 | uint4 | [0, 15] | See enum TIDE_RECORD_TYPE in Section 5. Type 1 is reference station. Type 2 is subordinate station. Others are as yet undefined.
all | header.latitude | float64 | int25, scale 100000 | [-167.77216, 167.77215] | Latitude in degrees north; use [-90.00000, 90.00000]. Lat,lng of 0,0 is interpreted as NULL.
all | header.longitude | float64 | int26, scale 100000 | [-335.54432, 335.54431] | Longitude in degrees east; use [-180.00000, 180.00000]. Lat,lng of 0,0 is interpreted as NULL.
all | header.reference_station | int32 | int18 | [-131072, 131071] | Index, references record_number of reference station for type 2 records, or -1 for none.
all | header.tzfile | int16 | uint10 | [0, 1023] | Index, references table of time zone values like ":America/New_York" that control which time zone output should be rendered into. These time zone values are defined in the zoneinfo time zone database that is included with most flavors of Unix. Not to be confused with zone_offset, which actually affects the calibration of the results relative to real time. See comments for zone_offset below.
all | header.name | char[90] | 0-terminated string | Length constrained by TIDE_RECORD. | Station name.
all | country | int16 | uint9 | [0, 511] | Index, references table of country names.
all | source | char[90] | 0-terminated string | Length constrained by TIDE_RECORD. | Where you got the data, or "" for NULL.
all | restriction | uint8 | uint4 | [0, 15] | Index, references table of restrictions like "Public domain," "Non-commercial use only," "DoD/DoD contractors only."
all | comments | char[10000] | 0-terminated string | Length constrained by TIDE_RECORD. | Human-readable text that is not provided to the user of a data set at the time of use but may be retrieved on demand. Use "" for NULL.
all | notes | char[10000] | 0-terminated string | Length constrained by TIDE_RECORD. | Human-readable text that MAY be delivered to the user of a data set at the time of use. XTide will print the notes in modes where this is convenient but ignore them when it is not.
all | legalese | uint8 | uint4 | [0, 15] | Index, references table of human-readable legal notices that MUST be delivered to the user of a data set at the time of use. Use 0 for NULL.
all | station_id_context | char[90] | 0-terminated string | Length constrained by TIDE_RECORD. | Name of the authority that has defined the Station ID, or "" for NULL.
all | station_id | char[90] | 0-terminated string | Length constrained by TIDE_RECORD. | An identifier for a tide station, defined by the authority specified in station_id_context, or "" for NULL.
all | date_imported | uint32 | uint27 | [0, 134217727] | The date on which the data set was imported into the database, encoded Year * 10000 + Month [1, 12] * 100 + Day [1, 31], or 0 for NULL. N.B., this is not the date of creation of the TCD file, but the date on record in a tide data management package such as Harmbase.
all xfields char[10000] 0-terminated string Length constrained by TIDE_RECORD. Space for backward-compatible addition of expansion fields as text. Encoding:
xfields: xfield*
xfield: field-name ":" field-value "\n"
field-name: [^:\n ]+
field-value: [^\n]* continuation*
continuation: "\n " field-value
When decoding field-values, the string "\n " is replaced by "\n" to unmangle multi-line values. (Yes, multi-line values remain multi-line, unlike RFC 822 headers.)
all | direction_units | uint8 | uint varying | [0, 255] | Index, references table of units like "degrees true." This field is used to indicate the units of the direction fields.
all | min_direction | int32 | uint9 | [0, 511] | Direction of ebb current. Use [0, 359], or 361 for NULL.
all | max_direction | int32 | uint9 | [0, 511] | Direction of flood current. Use [0, 359], or 361 for NULL.
all | level_units | uint8 | uint varying | [0, 255] | Index, references table of units like "feet," "meters," "knots," "knots^2." This field indicates the units of the datum and the amplitudes in type 1 records and the units of the level_add fields in type 2 records.*
1 | datum_offset | float32 | int28, scale 10000 | [-13421.7728, 13421.7727] | The datum (Z0).
1 | datum | int16 | uint7 | [0, 127] | Index, references table of datum kinds like "Mean Lower Low Water." For currents, set to 0 (value should be ignored).
1 | zone_offset | int32 | int13 | [-4096, 4095] | The standard time to which epochs are adjusted, a.k.a. the meridian, in hours and minutes east of UTC, encoded Hours * 100 + Minutes. zone_offset affects the calibration of the predictions relative to real time. Not to be confused with tzfile, which only affects which time zone the results are rendered into. For example, adjusting zone_offset will change high tide from 5:00 EST to 4:00 EST, while adjusting tzfile will change it from 5:00 EST to 4:00 CST (actually the same "real time" in two different time zones). Technically, zone_offset could be done away with by specifying that all data should be calibrated with UTC; however, this would make it more difficult to identify data sets with source data by visual inspection (all of the epochs would be different).
1 | expiration_date | uint32 | uint27 | [0, 134217727] | Use-until date for data set, encoded Year * 10000 + Month [1, 12] * 100 + Day [1, 31], or 0 for NULL.
1 | months_on_station | uint16 | uint10 | [0, 1023] | Number of months in time series used to derive harmonic constants, or 0 for NULL.
1 | last_date_on_station | uint32 | uint27 | [0, 134217727] | Last date in time series used to derive harmonic constants, encoded Year * 10000 + Month [1, 12] * 100 + Day [1, 31], or 0 for NULL.
1 | confidence | uint8 | uint4 | [0, 15] | A meaningless indicator of data quality, generally initialized to 10. (Jan wants to keep this.)
1 | amplitude | float32[255] | uint19, scale 10000 (each) | [0.0000, 52.4287] | Amplitudes of constituents. Constituents with amplitude less than AMPLITUDE_EPSILON are not encoded.
1 | epoch | float32[255] | uint16, scale 100 (each) | [0.00, 655.35] | Epochs (phases) of constituents, in degrees. Use [0.00, 359.99]. Constituents with amplitude less than AMPLITUDE_EPSILON are not encoded.
2 | min_time_add | int32 | int13 | [-4096, 4095] | The time adjustment for Low Tide or Max Ebb events, encoded Hours * 100 + Minutes. 0 and NULL are equivalent (no adjustment).** ***
2 | min_level_add | float32 | int17, scale 1000 | [-65.536, 65.535] | Additive adjustment for Low Tide or Max Ebb events.*** 0 and NULL are equivalent (no adjustment).
2 | min_level_multiply | float32 | uint16, scale 1000 | [0.000, 65.535] | Ratio for Low Tide or Max Ebb events, or 0 for NULL (equivalent to 1, no adjustment).***
2 | max_time_add | int32 | int13 | [-4096, 4095] | The time adjustment for High Tide or Max Flood events, encoded Hours * 100 + Minutes. 0 and NULL are equivalent (no adjustment).** ***
2 | max_level_add | float32 | int17, scale 1000 | [-65.536, 65.535] | Additive adjustment for High Tide or Max Flood events.*** 0 and NULL are equivalent (no adjustment).
2 | max_level_multiply | float32 | uint16, scale 1000 | [0.000, 65.535] | Ratio for High Tide or Max Flood events, or 0 for NULL (equivalent to 1, no adjustment).***
2 | flood_begins | int32 | int13 | [-4096, 4095] | The time adjustment for Slack Water or Min Flood before Max Flood, encoded Hours * 100 + Minutes, or 2560 for NULL.**
2 | ebb_begins | int32 | int13 | [-4096, 4095] | The time adjustment for Slack Water or Min Ebb before Max Ebb, encoded Hours * 100 + Minutes, or 2560 for NULL.**

* In case of units = knots^2 (hydraulic currents), it should be understood that only the amplitudes of the constants are such as to give results in knots squared. The datum and any level_add corrections are in plain knots; i.e., the square root of the amplitude is taken before the datum and any corrections are added in.

** Time corrections DO NOT incorporate adjustments to Local Standard Time when the reference and sub station are in different time zones. Time corrections are specified as if all calculations and predictions were done in UTC. Time zone differences are handled by adjusting the tzfile field. This differs from current NOS practice, in which LST adjustments are incorporated. When this "time warp" is undone for NOS sub stations that use reference stations across the International Date Line, time corrections in excess of 24 hours can result.

*** See https://flaterco.com/xtide/mincurrents.html regarding usage for Min Flood and Min Ebb events.

4. Public database header (version 2.2)

This section describes the "public portion" of the database header structure, which is declared in tcd.h and made available to applications via the get_tide_db_header operation.

char version[90];
libtcd version string.
uint32 major_rev;
libtcd major revision number.
uint32 minor_rev;
libtcd minor revision number.
char last_modified[90];
Last modification of TCD file.
uint32 number_of_records;
Number of records in TCD file.
int32 start_year;
Year corresponding to 0 index in speed, equilibrium argument, and node factor arrays.
uint32 number_of_years;
Number of years in speed, equilibrium argument, and node factor arrays.
uint32 constituents;
Number of constituents.
uint32 level_unit_types;
Number of entries in table used by get_level_units.
uint32 dir_unit_types;
Number of entries in table used by get_dir_units.
uint32 restriction_types;
Number of entries in table used by get_restriction.
uint32 datum_types;
Number of entries in table used by get_datum.
uint32 countries;
Number of entries in table used by get_country.
uint32 tzfiles;
Number of entries in table used by get_tzfile.
uint32 legaleses;
Number of entries in table used by get_legalese.
uint32 pedigree_types;
For backward compatibility. Ignore.

The encodings of constituent speeds, equilibrium arguments, and node factors are as follows.

Name | Program data type | File encoding | Encodable range | Semantics
Speed | float64 | uint varying (max 31), scale 10000000, with offset | [0.0000000, 214.7483647]* | Speed of constituent in degrees per hour.
Equilibrium argument | float32 | uint varying (max 31), scale 100, with offset | [0.00, bignum] | Equilibrium argument in degrees. Use [0.00, 359.99].
Node factor | float32 | uint varying (max 31), scale 10000, with offset | [0.0000, bignum] | Node factor.

The offsets are adjustments so that the minimum value in the data set is represented with a zero and the maximum by max−offset. For node factors, this can save bits. However, for speeds and equilibrium arguments they are a needless complication. Speeds in excess of the limit quoted above will overflow the integers before the offset is taken into account, and the minimum equilibrium argument is always zero anyway.

* The highest speed in the IHO list of constituents as of 2003-07-31 is 203.904625 degrees/hour for 6MS14.

5. libtcd 2.2.7 API

The API is provided in the C language and is made available by including the header file tcd.h.

#define NV_BYTE    int8_t
#define NV_INT16   int16_t
#define NV_INT32   int32_t
#define NV_INT64   int64_t
#define NV_U_BYTE  uint8_t
#define NV_U_INT16 uint16_t
#define NV_U_INT32 uint32_t
#define NV_U_INT64 uint64_t

#define NV_BOOL    unsigned char
#define NV_CHAR    char
#define NV_U_CHAR  unsigned char
#define NV_FLOAT32 float
#define NV_FLOAT64 double
This section may appear slightly different from one platform to the next. The build process for libtcd generates #includes and data type definitions as needed to provide integer types of specific sizes.
#define NVFalse         0
#define NVTrue          1
#define NV_U_INT32_MAX  4294967295
#define NV_INT32_MAX    2147483647
#define NV_U_INT16_MAX  65535
#define NV_INT16_MAX    32767
Defined values.
#define LIBTCD_VERSION   "PFM Software - libtcd v2.2.7 - 2015-08-09"
#define LIBTCD_MAJOR_REV 2
#define LIBTCD_MINOR_REV 2
These defines describe the version of libtcd to which the header file belongs.
/* One-line character strings */
#define ONELINER_LENGTH      90
/* Verbose character strings */
#define MONOLOGUE_LENGTH  10000
#define MAX_CONSTITUENTS    255
These defines describe the sizes of the fixed-size arrays in the tide record.
typedef struct ... DB_HEADER_PUBLIC;
typedef struct ... TIDE_STATION_HEADER;
typedef struct ... TIDE_RECORD;
The structure for the database header, and the header and main part of the tide record.
enum TIDE_RECORD_TYPE {REFERENCE_STATION=1, SUBORDINATE_STATION=2};
Syntactic sugar for values of header.record_type.
#define NULLSLACKOFFSET 0xA00
Magic constant used to indicate NULL in the flood_begins and ebb_begins fields of the tide record.
#define AMPLITUDE_EPSILON 0.00005
This is the level below which an amplitude rounds to zero.
void dump_tide_record (const TIDE_RECORD *rec);
Prints a low-level dump of the tide record to stderr.
NV_CHAR *get_country (NV_INT32 num);
NV_CHAR *get_tzfile (NV_INT32 num);
NV_CHAR *get_level_units (NV_INT32 num);
NV_CHAR *get_dir_units (NV_INT32 num);
NV_CHAR *get_restriction (NV_INT32 num);
NV_CHAR *get_datum (NV_INT32 num);
NV_CHAR *get_legalese (NV_INT32 num);
For fields in the tide record that are indices into tables of character string values, these functions are used to retrieve the character string value corresponding to a particular index. The value "Unknown" is returned when no translation exists. The return value is a pointer into static memory.
NV_CHAR *get_constituent (NV_INT32 num);
Get the name of the constituent corresponding to index num [0,constituents-1]. The return value is a pointer into static memory.
NV_CHAR *get_station (NV_INT32 num);
Get the name of the station whose record_number is num [0,number_of_records-1]. The return value is a pointer into static memory.
NV_FLOAT64 get_speed (NV_INT32 num);
Returns the speed of the constituent indicated by num [0,constituents-1].
NV_FLOAT32 get_equilibrium (NV_INT32 num, NV_INT32 year);
NV_FLOAT32 get_node_factor (NV_INT32 num, NV_INT32 year);
Get the equilibrium argument and node factor for the constituent indicated by num [0,constituents-1], for the year start_year+year.
NV_FLOAT32 *get_equilibriums (NV_INT32 num);
NV_FLOAT32 *get_node_factors (NV_INT32 num);
Get all available equilibrium arguments and node factors for the constituent indicated by num [0,constituents-1]. The return value is a pointer into static memory which is an array of number_of_years floats, corresponding to the years start_year through start_year+number_of_years-1.
NV_INT32 get_time (const NV_CHAR *string);
NV_CHAR *ret_time (NV_INT32 time);
NV_CHAR *ret_time_neat (NV_INT32 time);
Convert between character strings of the form "[+-]HH:MM" and the encoding Hours * 100 + Minutes. ret_time pads the hours with a leading zero when less than 10; ret_time_neat omits the leading zero and omits the sign when the value is 0:00. Returned pointers point into static memory.
NV_CHAR *ret_date (NV_U_INT32 date);
Convert the encoding Year * 10000 + Month [1, 12] * 100 + Day [1, 31] to a character string of the form "YYYY-MM-DD", or "NULL" if the value is zero. The returned pointer points into static memory. (The compact form, without hyphens, is obtainable just by printing the integer.)
NV_INT32 search_station (const NV_CHAR *string);
When invoked multiple times with the same string, returns record numbers of all stations that have that string anywhere in the station name. This search is case insensitive. When no more records are found it returns -1.
NV_INT32 find_station (const NV_CHAR *name);
NV_INT32 find_tzfile (const NV_CHAR *name);
NV_INT32 find_country (const NV_CHAR *name);
NV_INT32 find_level_units (const NV_CHAR *name);
NV_INT32 find_dir_units (const NV_CHAR *name);
NV_INT32 find_restriction (const NV_CHAR *name);
NV_INT32 find_datum (const NV_CHAR *name);
NV_INT32 find_constituent (const NV_CHAR *name);
NV_INT32 find_legalese (const NV_CHAR *name);
Inverses of the corresponding get_ operations. Return -1 for not found.
NV_INT32 add_restriction (const NV_CHAR *name, DB_HEADER_PUBLIC *db);
NV_INT32 add_tzfile (const NV_CHAR *name, DB_HEADER_PUBLIC *db);
NV_INT32 add_country (const NV_CHAR *name, DB_HEADER_PUBLIC *db);
NV_INT32 add_datum (const NV_CHAR *name, DB_HEADER_PUBLIC *db);
NV_INT32 add_legalese (const NV_CHAR *name, DB_HEADER_PUBLIC *db);
Add the value of name to the corresponding lookup table and return the index of the new value. If db is not NULL, the database header struct pointed to will be updated to reflect the changes. The maximum length of name is restricted by the corresponding size definition in tide_db_default.h (restriction 30, tzfile 30, country 50, datum 70, legalese 70, including the terminating null).
NV_INT32 find_or_add_restriction (const NV_CHAR *name, DB_HEADER_PUBLIC *db);
NV_INT32 find_or_add_tzfile (const NV_CHAR *name, DB_HEADER_PUBLIC *db);
NV_INT32 find_or_add_country (const NV_CHAR *name, DB_HEADER_PUBLIC *db);
NV_INT32 find_or_add_datum (const NV_CHAR *name, DB_HEADER_PUBLIC *db);
NV_INT32 find_or_add_legalese (const NV_CHAR *name, DB_HEADER_PUBLIC *db);
Add the value of name to the corresponding lookup table if and only if it is not already present. Return the index of the value. If db is not NULL, the database header struct pointed to will be updated to reflect the changes. The maximum length of name is restricted by the corresponding size definition in tide_db_default.h (restriction 30, tzfile 30, country 50, datum 70, legalese 70, including the terminating null).
void set_speed (NV_INT32 num, NV_FLOAT64 value);
Set the speed for the constituent corresponding to index num [0,constituents-1].
void set_equilibrium (NV_INT32 num, NV_INT32 year, NV_FLOAT32 value);
void set_node_factor (NV_INT32 num, NV_INT32 year, NV_FLOAT32 value);
Set the equilibrium argument and node factor for the constituent corresponding to index num [0,constituents-1], for the year start_year+year.
NV_BOOL open_tide_db (const NV_CHAR *file);
Opens the specified TCD file. If a different database is already open, it will be closed. libtcd maintains considerable internal state and can only handle one open database at a time. Returns false if the open failed.
void close_tide_db ();
Closes the open database.
NV_BOOL create_tide_db (const NV_CHAR *file, NV_U_INT32 constituents,
    NV_CHAR const * const constituent[], const NV_FLOAT64 *speed,
    NV_INT32 start_year, NV_U_INT32 num_years,
    NV_FLOAT32 const * const equilibrium[],
    NV_FLOAT32 const * const node_factor[]);
Creates a TCD file with the supplied constituents and no tide stations. Returns false if creation failed. The database is left in an open state.
DB_HEADER_PUBLIC get_tide_db_header ();
Returns a copy of the database header for the open database.
NV_BOOL get_partial_tide_record (NV_INT32 num, TIDE_STATION_HEADER *rec);
Gets "header" portion of tide record for the station whose record_number is num [0,number_of_records-1] and writes it into rec. Returns false if num is out of range. num is preserved in the static variable current_index.
NV_INT32 get_next_partial_tide_record (TIDE_STATION_HEADER *rec);
Invokes get_partial_tide_record for current_index+1. Returns the record number or -1 for failure.
NV_INT32 get_nearest_partial_tide_record (NV_FLOAT64 lat, NV_FLOAT64 lon,
                                          TIDE_STATION_HEADER *rec);
Invokes get_partial_tide_record for a station that appears closest to the specified lat and lon in the Cylindrical Equidistant projection. Returns the record number or -1 for failure.
NV_INT32 read_tide_record (NV_INT32 num, TIDE_RECORD *rec);
Gets tide record for the station whose record_number is num [0,number_of_records-1] and writes it into rec. num is preserved in the static variable current_record. Returns num, or -1 if num is out of range.
NV_INT32 read_next_tide_record (TIDE_RECORD *rec);
Invokes read_tide_record for current_record+1. Returns the record number or -1 for failure.
NV_BOOL add_tide_record (TIDE_RECORD *rec, DB_HEADER_PUBLIC *db);
#ifdef COMPAT114
/* Omission of db parameter was a bug. */
NV_BOOL update_tide_record (NV_INT32 num, TIDE_RECORD *rec);
#else
NV_BOOL update_tide_record (NV_INT32 num, TIDE_RECORD *rec, DB_HEADER_PUBLIC *db);
#endif
NV_BOOL delete_tide_record (NV_INT32 num, DB_HEADER_PUBLIC *db);
Add a new record, update an existing record, or delete an existing record. If the deleted record is a reference station, all dependent subordinate stations will also be deleted. Add and update return false if the new record is invalid; delete and update return false if the specified num is invalid or there is insufficient memory available. If db is not NULL, the database header struct pointed to will be updated to reflect the changes.
NV_BOOL infer_constituents (TIDE_RECORD *rec);
Computes inferred constituents when M2, S2, K1, and O1 are given and fills in the remaining unfilled constituents. The inferred constituents are developed or decided based on Article 230 of "Manual of Harmonic Analysis and Prediction of Tides," Paul Schureman, C&GS Special Publication No. 98, October 1971. Returns false if M2, S2, K1, or O1 is missing.

For more information, see Jan Depner, "Format for the Oceanographic and Atmospheric Master Library (OAML) Tide Constituent Database," rev. 2003-06-06.

6. V1 to V2 migration guide

libtcd vs. TCD file version compatibilities

libtcd 1 can only read and modify files written by v1. Versions of libtcd prior to 1.99 will fail inelegantly when attempting to read v2 files and will corrupt the database if a modification is attempted. Versions 1.99 and 1.100 will detect and report the version mismatch.

libtcd 2 can read files written by v1 or v2, but it can only create or modify v2 files. If it is necessary to create a v1 file, you must compile your application using libtcd 1. Version 1.100 is recommended for this purpose. It is available at https://flaterco.com/files/xtide/libtcd-1.100.tar.gz.

To convert a v1 TCD file to a v2 TCD file, use the application rewrite_tide_db in the package tcd-utils, available from https://flaterco.com/xtide/files.html.

Compiling old applications without changes

This option is for emergencies only, or in case of such extreme laziness that maintaining the version-integrity of the API is less important than avoiding minor changes to your applications.

Applications written against the TCD version 1 API should compile and run without changes using libtcd 2 if libtcd 2 is built with the COMPAT114 option, as follows:

bash-3.1$ ./configure --enable-COMPAT114

This will allow old applications to read and write version 2 TCD files. However, the resulting library is NOT API-compatible with libraries built in the normal way, which will break applications that are properly written for the v2 API. Therefore, any library built with this option is for local use only. Only a static library will be built.

Even with COMPAT114 enabled, some fields do not behave as they did in libtcd 1. Specifically, COMPAT114 does the following.

  • The preprocessor defines NAME_LENGTH, SOURCE_LENGTH and COMMENTS_LENGTH are provided.
  • The tide record field units is provided and is copied to and from level_units as needed to support reference stations.
  • The tide record fields pedigree, avg_level_units, min_avg_level, and max_avg_level are provided, but they are never used.
  • The deprecated functions get_pedigree, find_pedigree and add_pedigree are provided, but their behavior is to change all pedigrees to "Unknown."
  • The function update_tide_record accepts only two parameters (NV_INT32 num, TIDE_RECORD *rec).
  • The function check_simple is provided.
  • Reading of pre-version-1.02 TCD files with old style header checksums is supported.

The following subsections detail the application changes that are required and recommended to migrate to the version 2 API without COMPAT114.

Checklist of required changes when migrating applications from v1 API to v2 API

  1. Replace all uses of the units field with level_units.
  2. Replace all uses of NAME_LENGTH and SOURCE_LENGTH with ONELINER_LENGTH.
  3. Replace all uses of COMMENTS_LENGTH with MONOLOGUE_LENGTH.
  4. Provide a third parameter, DB_HEADER_PUBLIC *db, on each invocation of update_tide_record. It can be NULL if the calling function has no need of the db header.
  5. Stop using the tide record fields pedigree, units, avg_level_units, min_avg_level, and max_avg_level.
  6. Stop using the functions get_pedigree, find_pedigree, add_pedigree, and check_simple.

Checklist of optional changes when migrating applications from v1 API to v2 API

  1. Ensure that the max_direction and min_direction fields are initialized to 361 (the value indicating null) and/or set to their correct values when writing reference stations. Ensure that direction_units is set properly.
  2. Change variable data types and casts to match the new type of months_on_station. This was changed from unsigned char (uint8) to unsigned short (uint16) in libtcd 1.100.
  3. Change variable data types and casts to match the new types of the constituents and num_years parameters to create_tide_db and any fields in DB_HEADER_PUBLIC that were changed from signed to unsigned in libtcd 1.99.
  4. Make use of the new fields notes, legalese, xfields, station_id_context, station_id, and date_imported as appropriate.
  5. Make use of the new functions find_or_add..., ...legalese, get_equilibriums, get_node_factors, ret_time_neat, and ret_date as appropriate.
  6. When invoking functions that accept a DB_HEADER_PUBLIC *db parameter, if the db header has no use in the calling function except to fill in this parameter, a NULL can be passed instead.

7. Changelog

libtcd 2.2.7 release 2 (libtcd.so.1.0.2)

David Flater
2016-01-25

Updated the version strings in the prebuilt DOS/tcd.h and VS/tcd.h to match the current version.

Added m4_ifdef([AM_PROG_AR], [AM_PROG_AR]) to configure.ac.

Except for DOS and VS there is no need to update.

libtcd 2.2.7 (libtcd.so.1.0.2)

David Flater
2015-08-09

(Bug) When a field ended on a byte boundary, both bit_pack and bit_unpack were performing a do-nothing operation on the next byte. That is potentially an out-of-bounds access, so don't do that. Bug report credit: Mark Hayden.

libtcd 2.2.6 release 2 (libtcd.so.1.0.1)

David Flater
2014-10-25

(Portability) Added --enable-lm_hard configure option to support ARM Android. Simplified and cleaned up the build processes for DOS and Visual Studio.

Absolutely nothing was changed in the library itself. This is simply a repackaging and re-release of Version 2.2.6 with better build scripts and updated documentation. It is not necessary to "upgrade" if a previous release of Version 2.2.6 is already installed.

libtcd 2.2.6 (libtcd.so.1.0.1)

David Flater
2014-02-23

(Bug) Fixed search_station not resetting the search index after a database close/open. Bug report credit: Alan Dunham.

libtcd 2.2.5 release 3 (libtcd.so.1.0.0)

David Flater
2013-07-21

(Portability) Added build kit for DOS + DJGPP.

(Code rot) Regenerated all build scripts.

(Documentation rot) Updated documentation for Visual Studio 2012 and DJGPP.

Absolutely nothing was changed in the library itself. This is simply a repackaging and re-release of Version 2.2.5 with better build scripts and documentation. It is not necessary to "upgrade" if either previous release of Version 2.2.5 is already installed.

libtcd 2.2.5 release 2 (libtcd.so.1.0.0)

David Flater
2012-01-15

(Code rot) Regenerated all build scripts.

(Documentation rot) Updated documentation for Visual C++ 2010.

Absolutely nothing was changed in the library itself. This is simply a repackaging and re-release of Version 2.2.5 with better build scripts and documentation. It is not necessary to "upgrade" if Version 2.2.5 is already installed.

libtcd 2.2.5 (libtcd.so.1.0.0)

David Flater
2010-08-17

(Usability) Constified in-parameters in the API.

(Code rot) Tweaked configure.ac and Makefile.am and added m4 directory at the behest of libtoolize.

libtcd 2.2.4 (libtcd.so.0.0.4)

David Flater
2008-08-20

(x64 bug, tide_db.c) There were two mallocs where libtcd would throw an unwarranted assertion failure if successfully allocated memory happened to be 232-byte aligned. Bug report credit: Steven Roddis.

libtcd 2.2.3 (libtcd.so.0.0.3)

David Flater
2007-12-10

(Cleanup) Removed AM_MAINTAINER_MODE and made 'make dist-bzip2' do the right thing.

(Robustness) Checked return values of fread and fwrite. (Besides being the right thing to do, this should clean up Fedora build logs.)

(Usability) Print diagnostic in create_tide_db when fopen fails.

(Portability) With help from Leonid Tochinski, made portable to Visual C++ Express Edition.

  • Possibly include io.h instead of unistd.h.
  • Possibly use _chsize instead of ftruncate.
  • Possibly use #pragma message instead of #warning.

libtcd 2.2.2 (libtcd.so.0.0.2)

David Flater
2007-01-22

(Bugs, tide_db.c) Corrected more off-by-one errors in the use of calculate_bits by the function create_tide_db. The function write_tide_db_header was rounding values when it encoded them but create_tide_db was truncating them when it was calculating the number of bits. So if the maximum speed, equilibrium argument, or node factor value as encoded in integer form happened to round up to an exact power of 2, an invalid TCD file could have been produced.

(Nit, bit_pack.c) Eliminated the special case in calculate_bits to return 1 on the input 0. A field whose only possible value is 0 consumes no space in the TCD file but is correctly decoded as 0.

libtcd 2.2.1 (libtcd.so.0.0.1)

David Flater
2007-01-21

(Bug, bit_pack.c) Rewrote calculate_bits to eliminate ambiguous interpretation of "range" argument (now called "value"), eliminate the possibility of roundoff error, return the correct result in the case where the input value is 1, and, as a special case, return 1 if the input value is 0.

(Bugs, tide_db.c) Corrected off-by-one errors in the use of calculate_bits by the function create_tide_db.

The preceding issues could have resulted in the production of an invalid TCD file if the number of constituents, the number of distinct speed values, the number of distinct equilibrium argument values, or the number of distinct node factor values that were required by a particular database happened to be exactly a power of 2 (including 1). These conditions are unlikely to have occurred in normal use. I discovered the problems while attempting to generate a test case for XTide using exactly one constituent.

libtcd 2.2 (libtcd.so.0.0.0) release 2

David Flater
2006-11-26

Added warranty disclaimer to COPYING and libtcd.html. No source code changes.

libtcd 2.2 (libtcd.so.0.0.0)

David Flater
2006-11-22

Split out libtcd into a separate tarball (was previously bundled with XTide).

Started using automake and libtool; started building shared lib.

Resolved preprocessor define clash between automake and libtcd on VERSION.

Merged nvtypes.h and tide_db_version.h into tcd.h to reduce pollution of public include directories.

Removed extraneous #includes from tcd.h.

Changed COMPAT114 into a configure option (--enable-COMPAT114).

Caused tcd.h to be generated at configure time with the following substitutions.

  • COMPAT114 is defined or undefined per --enable-COMPAT114.
  • Version string reflects enabling of COMPAT114.
  • NV_ data type definitions and any pertinent #includes are synchronized with what configure found.

libtcd 2.1.3

David Flater
2006-10-05

Changed asserts with side-effects to use require macro instead.

Minor clean-ups.

libtcd 2.1.2

David Flater
2006-08-03

Improved configure script.

libtcd 2.1.1

David Flater
2006-08-02

Added configure script.

Cleaned up nvtypes.h.

Corrected date on version 2.1 (said 2005, was 2006).

libtcd 2.1

David Flater
2006-05-28

Fixed bug in delete_tide_record: linkage from subordinate stations to reference stations other than the one being deleted was getting broken. Bug report credit: August Hahn.

Fixed a memory management error in update_tide_record. Bug report credit: August Hahn.

Added enum for TIDE_RECORD_TYPE.

In update or delete_tide_record, if cannot allocate memory, return failure to the caller instead of exiting.

Added more error traps for invalid input.

Miscellaneous cleanups and nit fixes.

libtcd 2.0

David Flater
2004-10-15

Lots of changes to implement the revised database schema.

COMPAT114 is no longer defined by default in tcd.h (i.e. the v2 API is now effective).

Removed the unused define DEFAULT_NUMBER_OF_OBSOLETE_RECORDS from tide_db_default.h.

Fixed repeated reporting of amplitude/epoch errors.

Fixed wasted byte bug on speeds, equilibrium arguments, and node factors.

libtcd 1.100 "enhanced edition"

David Flater
2004-10-13

With luck, this will be the final release in the version 1 series and the last release that will write files that can be read by libtcd 1.02 through 1.14. It includes an additional round of cleanups that will enhance upward compatibilty but should not break backward compatibility.

check_simple was placed inside #ifdef COMPAT114 (which is still defined in tcd.h). AFAIK, this function is now of interest only in restore_tide_db, which uses it to determine which XML format to output.

Copied the libtcd.html descriptions of operations into the header file.

Made the db parameters to add_ and find_or_add_ operations optional (can be null).

Gave delete_tide_record a return value. Gave update_tide_record a db parameter, conditional on COMPAT114 not being defined.

In delete_tide_record, assert that the record is found.

Deleted unused systemtime var in write_tide_db_header.

Deleted unnecessary file parameter to read_tide_db_header.

Added static function check_tide_record to do sanity checks on records before committing them to the database and called it from add_tide_record and update_tide_record.

Initialized an uninitialized var in search_station.

Added clip_string calls in find_tzfile and find_constituent.

Replaced some weird code in find_constituent with more normal code.

Got rid of unnecessary copy operations in add_ functions.

Renamed tname parms to name.

Added checks to ensure that database is open when expected to be open and closed when expected to be closed.

Added AMPLITUDE_EPSILON and used it where applicable.

Moved duplicate record-size-figuring code into a new function, figure_size. Fixed wasted byte when record size is even multiple of 8 bits. (The same bug exists for calculating the size of the speeds, equilibrium arguments, and node factors, but fixing that would break compatibility, and the wastage is at most 3 bytes.)

Changed months_on_station to uint16.

Fixed bounds checking on input to add_ functions -- they all have their own static limits. Added similar bounds checking in write_tide_db_header.

Lots of documentation nits fixed.

libtcd 1.99 "collector's edition"

David Flater
2004-10-05

With luck, this will be the final release in the version 1 series and the last release that will write files that can be read by libtcd 1.02 through 1.14. It includes a gigantic round of cleanups to libtcd code that were made in anticipation of the upcoming major revision. Except for the bug fixes, the changes should be invisible to all wholesome client applications. Unwholesome client code or the use of unwholesome databases built by old, buggy versions of libtcd may now trigger errors or warnings that did not appear with libtcd 1.14.

In the process of testing the cleanups, I discovered some unrelated, really horrible bugs.

(Bug) Constituents with zero phases were not being encoded by write_tide_record. The affected reference stations in harmonics-dwf-2004-09-14 are Delfzijl, Netherlands; The Battery, New York Harbor, NY; and South Pass, LA. write_tide_record now encodes any constituent with a positive amplitude. Constituents with zero amplitude but nonzero phase are dropped, and negative amplitudes yield assertion failures. Made analogous changes to update_tide_record (the counts were supposed to match).

(Bug) update_tide_record was counting constituents for subordinate stations.

(Bug) Backed out the change to the control flow in delete_tide_record made in 1.14, which broke the deletion of reference stations with sub stations.

(Bug) Fixed logic error in delete_tide_record that corrupted the database when reference stations with sub stations were deleted.

(Bug) Made read_next_tide_record return -1 if at end of file, instead of going off the deep end.

Following are details of the gigantic cleanup.

The defines NAME_LENGTH, SOURCE_LENGTH and COMMENTS_LENGTH were generalized to ONELINER_LENGTH to set the length of one-line character string buffers and MONOLOGUE_LENGTH to set the length of verbose character string buffers.

COMPAT114 is defined in tcd.h. The effects are:

  • NAME_LENGTH, SOURCE_LENGTH and COMMENTS_LENGTH get defined.
  • Pre-version-1.02 TCD files using the old checksum code are accepted.

Added commentary on the commentary about OS-specific defines in nvtypes.h and tide_db_header.h, noting that they are not actually used.

Cleaned up all warnings and errors compiling under g++ -Wall:

  • (Errors) Corrected casts in union initializers in tide_db_header.h.
  • (Warnings) Added casts or changed data types, as appropriate, to resolve flagged signed-unsigned conversions.
  • (Errors) Added casts where NV_U_BYTE buffers were passed to functions from string.h (invalid conversion from unsigned char* to const char*).

Added asserts everywhere that I came across potentially dangerous assumptions.

Changed -O2 to -O in Makefile (Forte doesn't like O2).

Moved changelogs from source files to libtcd.html.

Made write_tide_record static; no applications should be calling this directly.

In clip_string, expanded static buffer to MONOLOGUE_LENGTH, fixed a bug that was previously masked, simplified code and added bounds checking.

Eliminated repeated calls to clip_string in find functions.

Eliminated clip_string duplication in write_tide_record.

Changed 256-char static buffers in add_pedigree, add_tzfile, add_country, add_datum, and add_restriction to ONELINER_LENGTH and added bounds checking.

Made filename MONOLOGUE_LENGTH.

Made version and last_modified ONELINER_LENGTH.

Handled overlong strings in TCD file by complaining and truncating instead of returning garbarge.

Eliminated get_string.

Eliminated repeated parsing of input in read_tide_db_header. Changed input buffer size to ONELINER_LENGTH.

Made support for pre-version-1.02 header checksums conditional on COMPAT114.

Changed many int32 fields in the DB header that had no reason ever to be negative to uint32. Exceptions include start_year (in case some crazy goes B.C.) and the offsets for speeds, equilibrium arguments, and node factors (required to read pre-version-1.11 TCD files). Also changed record_size in the tide record header, but left alone the rest of the tide record because the risk of breaking client code is too great: build_tide_db temporarily stores negative results from find functions in these fields, and tideEditor puts -1 in the record_number field to flag a new record. -1 in reference_station means no reference, though normally it's only -1 for reference stations.

In signature of create_tide_db, constituents and num_years became unsigned.

Changed many looper, index, size, etc. variables from signed to unsigned.

Corrected unsigned scan formats in read_tide_db_header.

Removed unused fields, unused data types and overcomplicated infrastructure in tide_db_header.h and read_tide_db_header.

Corrected signature of bit_unpack in tide_db.c.

Made get_speed, get_equilibrium and get_node_factor give assertion failures instead of returning -1.0 when invoker attempts to retrieve nonsense values. Added a missing bounds check.

Made set_speed, set_equilibrium and set_node_factor give assertion failures instead of doing nothing when invoker attempts to set nonsense values. Added a missing bounds check.

Made record_size in TIDE_INDEX struct 32 bits.

Added a warning about TCD files with negative offsets for speeds, eq args or node factors (caused by the bug fixed in 1.11).

Changed format of date string in [LAST MODIFIED] to XTide style. Changed identifer in [VERSION] to libtcd.

Added these functions:

  • NV_FLOAT32 *get_equilibriums (NV_INT32 num);
  • NV_FLOAT32 *get_node_factors (NV_INT32 num);
  • NV_INT32 find_or_add_restriction (NV_CHAR *tname, DB_HEADER_PUBLIC *db);
  • NV_INT32 find_or_add_tzfile (NV_CHAR *tname, DB_HEADER_PUBLIC *db);
  • NV_INT32 find_or_add_country (NV_CHAR *tname, DB_HEADER_PUBLIC *db);
  • NV_INT32 find_or_add_datum (NV_CHAR *tname, DB_HEADER_PUBLIC *db);
  • NV_CHAR *ret_time_neat (NV_INT32 time);
  • NV_CHAR *ret_date (NV_U_INT32 date);

Added header fields for major and minor revision number. Added check for attempt to read higher major revision than supported.

libtcd 1.14

David Flater
2004-09-03

(tide_db.c) Certain database update operations that ended with closing and re-opening the database were broken by nulling out the filename in close_tide_db. Incorporated patch from Jan Depner that rectifies this and tweaks the control flow in delete_tide_record.

libtcd 1.13

David Flater
2004-08-15

(create_tide_db) Write a valid end_of_file record even if someone creates a database with no tide records.

(tide_db_default) Removed a superfluous space character in table of default datum types (after Lowest Astronomical Tide).

libtcd 1.12

David Flater
2003-12-04

(tcd.h) Deleted #include <malloc.h>.

libtcd 1.11

David Flater
2003-11-16

(create_tide_db) Fixed horrible bug: offsets for speeds, equilibrium args, and node factors were sign-reversed with respect to their usage in read_tide_db_header and write_tide_db_header, resulting in possible overflows.

(read_tide_db_header) Added handling for zero tide records, which happens on new database create.

(open_tide_db) Added check of modified flag to 2003-10-14 code.

(close_tide_db) Deleted repeat free of tindex introduced 2003-10-14. Cleared modified flag on close.

libtcd 1.10

David Flater
2003-10-14

Incorporated patch from Phil Thornton that closes a memory leak and improves performance on repeat calls to open_tide_db. See https://flaterco.com/xtide/tcd_notes.html

libtcd 1.09

Jan C. Depner
2003-09-04

Bug fix - modifying last record in file and changing size of record caused a big problem. Duh, I should have seen that one coming.

libtcd 1.08

Jan C. Depner
2003-07-23

Bug fix - deleting last record in file caused a big problem.

libtcd 1.07

David Flater
2003-03-27

(This version was also released briefly without an updated version string.)

Check_simple altered per resolution to abolish "simplified" type 2 records. See https://flaterco.com/xtide/tcd_notes.html

libtcd 1.06

David Flater
2003-03-18

(This version failed to report an updated version string.)

Added NULLSLACKOFFSET to tcd.h per 2003-03-18 change to slack offsets. See https://flaterco.com/xtide/tcd_notes.html

libtcd 1.05

David Flater
2003-03-11

Incorporated nit fixes from August Hahn: added clip_string(tname) to take care of cases when the country name had leading/trailing spaces, and removed a couple of unused variables.

libtcd 1.04

David Flater
2002-12-13

While integrating 1.03, deleted an unused variable (whoop de do).

libtcd 1.03

Wade Ladner/Jan C. Depner
2002-12-09

Small fix for Micro$oft Windoze. We don't need to add CR's to strings (apparently).

libtcd 1.02

August Hahn
2002-11-15

Replaced the simplistic checksum with a real CRC. If the first checksum fails it will check for an old-style checksum.

libtcd 1.01

David Flater
2002-10-01

Many changes since 2002-08-01. Bumped version upon integration with XTide distribution. Renamed resulting library to libtcd.

tidelib 1.00

Jan C. Depner
2002-08-01

First tested release.

tidelib 0.99

Jan C. Depner
2002-07-15

Prototype for testing.

8. References

Jan Depner, "Format for the Oceanographic and Atmospheric Master Library (OAML) Tide Constituent Database," rev. 2003-06-06.

libtcd version 1.100.

XTide.

ISO-8859-1.

Manual of Harmonic Analysis and Prediction of Tides. Special Publication No. 98, Revised (1940) Edition (reprinted 1958 with corrections; reprinted again 1994). United States Government Printing Office, 1994.


Location list

Location list generated 2018-12-27 1:01 PM EST

Station ID | Name | Type | Latitude | Longitude
PCT3896_1 | 0.2 mile off Flat Point, Taku Inlet, Stephens Passage, Alaska Current | Sub | 58.3333° N | 134.0500° W
PCT3901_1 | 0.2 mile off Taku Point, Taku Inlet, Stephens Passage, Alaska Current | Sub | 58.4000° N | 134.0167° W
ACT8491_1 | 0.5 mile southeast of, Pinellas Point, Tampa Bay, Florida Current | Sub | 27.6970° N | 82.6325° W
8537731 | 0.8 n.mi. above entrance, Alloway Creek, New Jersey | Sub | 39.4967° N | 75.5167° W
8537535 | 1 n.mi. above entrance, Mad Horse Creek, New Jersey | Sub | 39.4317° N | 75.4467° W
ACT8496_1 | 1.9 miles SE of, Pinellas Point, Tampa Bay, Florida Current | Sub | 27.6847° N | 82.6097° W
8677833 | 2.5 miles above mouth, Little Satilla River, Georgia | Sub | 31.0583° N | 81.4933° W
8537753 | 2.5 n.mi. above entrance, Alloway Creek, New Jersey | Sub | 39.5050° N | 75.4833° W
ACT8486_1 | 2.6 miles south of, Pinellas Point, Tampa Bay, Florida Current | Sub | 27.6605° N | 82.6417° W
PCT0101_1 | 28th St. Pier (San Diego), 0.35 nmi. SW (Depth 14ft), San Diego Bay, California Current | Sub | 32.6828° N | 117.1428° W
PCT0101_2 | 28th St. Pier (San Diego), 0.35 nmi. SW (Depth 28ft), San Diego Bay, California Current | Sub | 32.6828° N | 117.1428° W
PCT0096_1 | 28th St. Pier (San Diego), 0.92 nmi. SW (Depth 7ft), San Diego Bay, California Current | Sub | 32.6747° N | 117.1495° W
8722481 | 3 miles above A1A highway bridge, Loxahatchee River, Florida | Sub | 26.9700° N | 80.1267° W
ACT8501_1 | 3 miles southeast of, Pinellas Point, Tampa Bay, Florida Current | Sub | 27.6730° N | 82.5930° W
ACT7616_1 | 610 Statute Mile Mark (Depth 6ft), Bear River, St. Catherines Sound, Georgia Current | Sub | 31.8105° N | 81.1767° W
8677566 | 8 miles above mouth, Little Satilla River, Georgia | Sub | 31.0983° N | 81.5733° W
8722492 | A1A highway bridge, Loxahatchee River, Florida | Sub | 26.9467° N | 80.0900° W
8666283 | Abbapoola Creek entrance, Stono River, South Carolina | Sub | 32.6767° N | 80.0067° W
8537774 | Abbots Meadow, Alloway Creek, New Jersey | Sub | 39.5117° N | 75.4933° W
9441187 | Aberdeen, Grays Harbor, Washington | Ref | 46.9683° N | 123.8530° W
8534638 | Absecon Channel, State Route 87 bridge, New Jersey | Sub | 39.3850° N | 74.4250° W
8534540 | Absecon, Absecon Creek, U.S. Hwy. 30 bridge, New Jersey | Sub | 39.4233° N | 74.5000° W
9461406 | Adak Bight, Adak Island, Alaska | Sub | 51.7700° N | 176.4350° W
8723453 | Adams Key, south end, Biscayne Bay, Florida | Sub | 25.3967° N | 80.2333° W
9447905 | Admiralty Head, Admiralty Inlet, Washington | Sub | 48.1583° N | 122.6680° W
9462317 | Adugak Island, Aleutian Islands, Alaska | Sub | 52.9117° N | 169.1650° W
9455120 | Agnes Cove, Aialik Peninsula, Alaska | Ref | 59.7733° N | 149.5880° W
9455120 | Agnes Cove, Aialik Peninsula, Alaska (sub) | Sub | 59.7733° N | 149.5880° W
9759412 | Aguadilla, Crashboat Beach, Puerto Rico | Ref | 18.4566° N | 67.1646° W
9456901 | Aguchik Island, Kukak Bay, Alaska | Ref | 58.2900° N | 154.2700° W
9456901 | Aguchik Island, Kukak Bay, Alaska (sub) | Sub | 58.2900° N | 154.2700° W
9455145 | Aialik Bay, north end, Alaska | Ref | 59.9533° N | 149.7150° W
9455145 | Aialik Bay, north end, Alaska (sub) | Sub | 59.9533° N | 149.7150° W
9455146 | Aialik Sill, Aialik Bay, Alaska | Ref | 59.8850° N | 149.7180° W
9455146 | Aialik Sill, Aialik Bay, Alaska (sub) | Sub | 59.8850° N | 149.7180° W
TPT2701 | Ailinglapalap Atoll, Marshall Islands | Sub | 7.2833° N | 168.7500° E
TPT2711 | Ailuk Atoll, Marshall Islands | Sub | 10.2167° N | 169.9833° E
8666749 | Airy Hall Plantation, Ashepoo River, South Carolina | Sub | 32.6317° N | 80.4717° W
PCT2821_1 | Ajax Reef, Felice Strait, Alaska Current | Sub | 55.0000° N | 131.4667° W
9468283 | Akeftapak, St. Lawrence Island, Alaska | Ref | 63.7185° N | 171.6447° W
9462719 | Akun Cove, Akun Island, Aleutian Islands, Alaska | Ref | 54.2333° N | 165.5330° W
9462691 | Akutan Harbor, Akutan Island, Aleutian Islands, Alaska | Sub | 54.1283° N | 165.8080° W
9462694 | Akutan, Aleutian Islands, Alaska | Ref | 54.1333° N | 165.7773° W
9447993 | Ala Spit, Whidbey Island, Washington | Sub | 48.3967° N | 122.5870° W
8730667 | Alabama Point, Perdido Pass, Alabama | Ref | 30.2786° N | 87.5550° W
9414632 | Alameda Creek, San Francisco Bay, California | Sub | 37.5950° N | 122.1450° W
9414767 | Alameda Naval Air Station fuel pier, San Francisco Bay, California | Ref | 37.7933° N | 122.3150° W
9414767 | Alameda Naval Air Station fuel pier, San Francisco Bay, California (sub) | Sub | 37.7933° N | 122.3150° W
9414750 | Alameda, San Francisco Bay, California | Ref | 37.7717° N | 122.3000° W
9414750 | Alameda, San Francisco Bay, California (sub) | Sub | 37.7717° N | 122.3000° W
8518995 | Albany, Hudson River, New York | Ref | 42.6500° N | 73.7467° W
9459464 | Albatross Anchorage, Balboa Bay, Alaska | Sub | 55.5900° N | 160.6130° W
8667909 | Albergottie Creek, Rt. 21 bridge, Beaufort River, South Carolina | Sub | 32.4500° N | 80.7317° W
TWC2309 | Alcan Harbor, Shemya Island, Aleutian Islands, Alaska | Sub | 52.7167° N | 174.0667° E
9414792 | Alcatraz Island, San Francisco Bay, California | Sub | 37.8267° N | 122.4170° W
9449994 | Aleck Bay, Lopez Island, Washington | Sub | 48.4250° N | 122.8530° W
8634214 | Alexandria, Potomac River, Virginia | Sub | 38.8050° N | 77.0383° W
9457804 | Alitak, Lazy Bay, Alaska | Ref | 56.8974° N | 154.2480° W
9457804 | Alitak, Lazy Bay, Alaska (sub) | Sub | 56.8974° N | 154.2480° W
PCT4191_1 | Allan Pt., 1.5mile W of, Nakwasina Passage, Alaska Current | Sub | 57.2500° N | 135.4333° W
8729015 | Allanton, East Bay, St. Andrew Bay, Florida | Sub | 30.0300° N | 85.4650° W
TEC3515 | Allied Chemical Corp. docks, Turtle River, Georgia | Sub | 31.1833° N | 81.5167° W
8729152 | Alligator Bayou, St. Andrew Bay, Florida | Sub | 30.1700° N | 85.7550° W
8728288 | Alligator Point, St. James Island, Apalachee Bay, Florida | Sub | 29.9033° N | 84.4133° W
8771801 | Alligator Point, West Bay, Texas | Sub | 29.1667° N | 95.1250° W
8723861 | Alligator Reef, Hawk Channel, Florida | Sub | 24.8500° N | 80.6183° W
8661608 | Allston Creek, Murrells Inlet, South Carolina | Sub | 33.5317° N | 79.0533° W
9446281 | Allyn, Case Inlet, Puget Sound, Washington | Sub | 47.3833° N | 122.8230° W
ACT2076_1 | Almy Point Bridge, south of, Sakonnet River (Depth 15ft), Rhode Island Current | Sub | 41.6217° N | 71.2200° W
8530095 | Alpine, Hudson River, New Jersey | Sub | 40.9450° N | 73.9183° W
9450382 | Alva Bay, Revillagigedo Island, Alaska | Sub | 55.2283° N | 131.1330° W
PCT5426_1 | Amak Island, 5 miles north of, Alaska Current | Sub | 55.5000° N | 163.1667° W
PCT5431_1 | Amak Island, 5 miles southeast of, Alaska Current | Sub | 55.3500° N | 163.0167° W
9462987 | Amak Island, Bristol Bay, Alaska | Sub | 55.4133° N | 163.1150° W
8720086 | Amelia City, South Amelia River, Florida | Sub | 30.5867° N | 81.4633° W
8443662 | Amelia Earhart Dam, Mystic River, Boston Harbor, Massachusetts | Ref | 42.3950° N | 71.0767° W
8443662 | Amelia Earhart Dam, Mystic River, Boston Harbor, Massachusetts (sub) | Sub | 42.3950° N | 71.0767° W
9450125 | American Bay, Kaigani Strait, Alaska | Sub | 54.8500° N | 132.8300° W
8515864 | Amityville, Great South Bay, New York | Sub | 40.6550° N | 73.4183° W
ACT6861_1 | Amoco Pier, off, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.9592° N | 79.9180° W
8530696 | Amtrak RR. swing bridge, Hackensack River, New Jersey | Sub | 40.7517° N | 74.0967° W
TWC2229 | Amukta Island, north side, Aleutian Islands, Alaska | Sub | 52.5167° N | 171.2333° W
9448794 | Anacortes, Guemes Channel, Washington | Sub | 48.5183° N | 122.6200° W
9455606 | Anchor Point, Cook Inlet, Alaska | Ref | 59.7720° N | 151.8670° W
9455606 | Anchor Point, Cook Inlet, Alaska (sub) | Sub | 59.7720° N | 151.8670° W
9451317 | Anchor Point, Wrangell Narrows, Alaska | Ref | 56.6383° N | 132.9270° W
9451317 | Anchor Point, Wrangell Narrows, Alaska (sub) | Sub | 56.6383° N | 132.9270° W
PCT3766_1 | Anchor Point, Wrangell Narrows, Alaska Current | Sub | 56.6395° N | 132.9312° W
9455920 | Anchorage, Knik Arm, Cook Inlet, Alaska | Ref | 61.2375° N | 149.8904° W
8726917 | Anclote Lighthouse, Anclote Key, Florida | Ref | 28.1650° N | 82.8433° W
8726924 | Anclote, Anclote River, Florida | Sub | 28.1717° N | 82.7850° W
9462578 | Anderson Bay, Unalaska Island, Alaska | Sub | 53.6783° N | 166.8320° W
9457259 | Andreon Bay, Shuyak Island, Alaska | Sub | 58.5183° N | 152.4150° W
8722937 | Andrews Avenue bridge, New River, Fort Lauderdale, Florida | Sub | 26.1183° N | 80.1450° W
8417377 | Androscoggin River entrance, Kennebec River, Maine | Sub | 43.9500° N | 69.8883° W
9414817 | Angel Island (west side), San Francisco Bay, California | Sub | 37.8600° N | 122.4430° W
9414818 | Angel Island, East Garrison, San Francisco Bay, California | Sub | 37.8633° N | 122.4200° W
9450679 | Anguilla Island, Gulf of Esquibel, Alaska | Sub | 55.6833° N | 133.5870° W
8722274 | Ankona, Indian River, Florida | Sub | 27.3550° N | 80.2733° W
8726243 | Anna Maria Key, Bradenton Beach, Florida | Sub | 27.4967° N | 82.7133° W
8726282 | Anna Maria Key, city pier, Florida | Sub | 27.5333° N | 82.7300° W
8575512 | Annapolis (US Naval Academy), Severn River, Maryland | Ref | 38.9833° N | 76.4816° W
8575512 | Annapolis (US Naval Academy), Severn River, Maryland (sub) | Sub | 38.9833° N | 76.4816° W
8724229 | Annette Key, north end, Big Spanish Channel, Florida | Sub | 24.7583° N | 81.3900° W
8441571 | Annisquam, Lobster Cove, Massachusetts | Sub | 42.6550° N | 70.6767° W
9413878 | Ano Nuevo Island, California | Sub | 37.1083° N | 122.3380° W
8450948 | Anthony Point, Sakonnet River, Rhode Island | Sub | 41.6383° N | 71.2117° W
9415064 | Antioch, San Joaquin River, California | Ref | 38.0200° N | 121.8150° W
9415064 | Antioch, San Joaquin River, California (sub) | Sub | 38.0200° N | 121.8150° W
8728711 | Apalachicola River (A&N RR bridge), Apalachicola Bay, Florida | Ref | 29.7633° N | 85.0333° W
8728711 | Apalachicola River (A&N RR bridge), Apalachicola Bay, Florida (sub) | Sub | 29.7633° N | 85.0333° W
8728690 | Apalachicola, Apalachicola Bay, Florida | Ref | 29.7267° N | 84.9817° W
PCT5881_1 | Apavawook Cape, 1 mile south of, St. Lawrence Island, Alaska Current | Sub | 63.1167° N | 168.9333° W
8571072 | Ape Hole Creek, Pocomoke Sound, Chesapeake Bay, Maryland | Sub | 37.9617° N | 75.8217° W
9466079 | Apokak Creek entrance, Alaska | Sub | 60.1367° N | 162.1580° W
PCT5836_1 | Apokak Creek entrance, Kuskokwim Bay, Alaska Current | Sub | 60.1333° N | 162.1667° W
8726537 | Apollo Beach, Hillsborough Bay, Tampa Bay, Florida | Sub | 27.7867° N | 82.4267° W
TWC2405 | Apoon Mouth, Yukon River, Norton Sound, Alaska | Sub | 63.0500° N | 163.3833° W
9462239 | Applegate Cove, Chuginadak Island, Aleutian Islands, Alaska | Sub | 52.8617° N | 169.8620° W
9454794 | Applegate Island, Prince William Sound, Alaska | Sub | 60.6233° N | 148.1650° W
ACT6331_1 | Approach, Beaufort Inlet, North Carolina Current | Sub | 34.6717° N | 76.6700° W
1630000 | Apra Harbor, Guam | Ref | 13.4434° N | 144.6564° E
8634858 | Aquia Creek, Potomac River, Virginia | Sub | 38.4183° N | 77.3533° W
ACT8896_1 | Aransas Pass (Depth 15ft), Texas Current | Sub | 27.8338° N | 97.0442° W
ACT8896_3 | Aransas Pass (Depth 50ft), Texas Current | Sub | 27.8338° N | 97.0442° W
ACT8896_2 | Aransas Pass, Texas Current (35d) | Ref | 27.8338° N | 97.0442° W
8774230 | Aransas Wildlife Refuge (TCOON), Texas | Ref | 28.2283° N | 96.7950° W
8775241 | Aransas, Aransas Pass, Texas | Ref | 27.8366° N | 97.0391° W
9446666 | Arcadia, Totten Inlet, Puget Sound, Washington | Sub | 47.1967° N | 122.9380° W
9418851 | Arcata Wharf, Humboldt Bay, California | Sub | 40.8500° N | 124.1170° W
9757809 | Arecibo, Puerto Rico | Ref | 18.4805° N | 66.7024° W
9416841 | Arena Cove, California | Ref | 38.9146° N | 123.7111° W
8727097 | Aripeka, Hammock Creek, Florida | Sub | 28.4333° N | 82.6683° W
9446491 | Arletta, Hale Passage, Puget Sound, Washington | Sub | 47.2800° N | 122.6520° W
9449932 | Armitage Island, Thatcher Pass, Washington | Ref | 48.5350° N | 122.7970° W
8664662 | Army Depot, Cooper River, South Carolina | Ref | 32.9100° N | 79.9517° W
TPT2723 | Arno Atoll, Marshall Islands | Sub | 7.1333° N | 171.7000° E
ACT6216_1 | Arnold Point, 0.4 mile west of, Elk River, Maryland Current | Sub | 39.4638° N | 75.9742° W
TEC4737 | Arroyo, Puerto Rico | Sub | 17.9667° N | 66.0667° W
8537614 | Artificial Island, Salem Nuclear Plant, Delaware River, New Jersey | Sub | 39.4600° N | 75.5317° W
8661741 | Arundel Plantation, Great Pee Dee River, South Carolina | Sub | 33.4833° N | 79.1783° W
ACT7121_1 | Ashe Island Cut, SW of, Coosaw River (Depth 15ft), South Carolina Current | Sub | 32.5100° N | 80.5050° W
ACT7126_1 | Ashe Island Cut, St. Helena Sound (Depth 6ft), South Carolina Current | Sub | 32.5200° N | 80.4883° W
ACT7096_1 | Ashepoo Coosaw Cutoff (Depth 6ft), South Carolina Current | Sub | 32.5250° N | 80.4533° W
ACT7106_1 | Ashepoo River, off Jefford Creek entrance, South Carolina Current | Sub | 32.5067° N | 80.4100° W
8665814 | Ashepoo, Ashepoo River, South Carolina | Sub | 32.7433° N | 80.5567° W
8667482 | Ashepoo-Coosaw Cutoff, ICWW, Ashepoo River, South Carolina | Sub | 32.5250° N | 80.4517° W
8630413 | Assateague Beach, Toms Cove, Virginia | Sub | 37.8650° N | 75.3683° W
8539058 | Assiscunk Creek, Route 130 bridge, New Jersey | Sub | 40.0733° N | 74.8483° W
9439023 | Astoria (Port Docks), Oregon | Sub | 46.1867° N | 123.8600° W
9439026 | Astoria (Youngs Bay), Oregon | Sub | 46.1717° N | 123.8420° W
9461555 | Atka Pass, east end, Atka Island, Alaska | Sub | 52.0067° N | 175.3200° W
9461710 | Atka, Nazan Bay, Atka Island, Alaska | Ref | 52.2320° N | 174.1726° W
8656499 | Atlantic Beach Bridge, North Carolina | Sub | 34.7183° N | 76.7367° W
8516881 | Atlantic Beach, East Rockaway Inlet, Long Island, New York | Ref | 40.5950° N | 73.7433° W
8720259 | Atlantic Beach, Florida | Sub | 30.3350° N | 81.3950° W
8534720 | Atlantic City, New Jersey | Ref | 39.3550° N | 74.4183° W
8423635 | Atlantic Heights, Piscataqua River, New Hampshire | Sub | 43.0900° N | 70.7633° W
8531662 | Atlantic Highlands, Sandy Hook Bay, New Jersey | Sub | 40.4183° N | 74.0350° W
8423005 | Atlantic Terminals T14A, New Hampshire | Ref | 43.1167° N | 70.8117° W
9460150 | Attu, Massacre Bay, Alaska | Ref | 52.8400° N | 173.1950° E
8538274 | Auburn, Oldmans Creek, Delaware River, New Jersey | Sub | 39.7150° N | 75.3600° W
8417144 | Augusta, MCRR Bridge, Kennebec River, Maine | Ref | 44.3200° N | 69.7703° W
9452263 | Auke Bay, Alaska | Sub | 58.3817° N | 134.6450° W
PCT3946_1 | Aurora Basin, SW of (Depth 15ft), Gastineau Channel, Stephens Passage, Alaska Current | Sub | 58.3050° N | 134.4408° W
8571901 | Avalon, Dogwood Harbor, Chesapeake Bay, Maryland | Sub | 38.7100° N | 76.3350° W
9410079 | Avalon, Santa Catalina Island, California | Ref | 33.3450° N | 118.3250° W
9410079 | Avalon, Santa Catalina Island, California (sub) | Sub | 33.3450° N | 118.3250° W
8653951 | Avon Seafood dock, Peter's Ditch, Avon, North Carolina | Ref | 35.3501° N | 75.5120° W
9445388 | Ayock Point, Washington | Sub | 47.5083° N | 123.0520° W
8515421 | Babylon, Great South Bay, New York | Sub | 40.6850° N | 73.3150° W
8418175 | Back Cove, Casco Bay, Maine | Sub | 43.6767° N | 70.2550° W
8537116 | Back Creek entrance, Nantuxent Cove, Delaware Bay, New Jersey | Sub | 39.3050° N | 75.2783° W
8664131 | Back River Reservoir, West Branch, Cooper River, South Carolina | Sub | 32.9950° N | 79.9367° W
ACT7811_1 | Back River entrance (Depth 10ft), St. Simons Sound, Georgia Current | Sub | 31.1483° N | 81.4417° W
ACT7811_2 | Back River entrance (Depth 18ft), St. Simons Sound, Georgia Current | Sub | 31.1483° N | 81.4417° W
ACT6856_1 | Back River entrance, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.9683° N | 79.9333° W
8416961 | Back River, Sheepscot River, Maine | Sub | 43.9583° N | 69.6833° W
8664531 | Bacon Bridge, Ashley River, South Carolina | Sub | 32.9583° N | 80.2033° W
8724138 | Bahia Honda Key, Bahia Honda Channel, Florida | Sub | 24.6550° N | 81.2817° W
8722939 | Bahia Mar Yacht Club, Fort Lauderdale, Florida | Sub | 26.1133° N | 80.1083° W
9759197 | Bahía Salinas, Puerto Rico | Ref | 17.9514° N | 67.1966° W
8678322 | Bailey Cut, 0.8 mile west of, Satilla River, Georgia | Ref | 30.9850° N | 81.5917° W
8668482 | Baileys Landing, Okatee River, Colleton River, South Carolina | Sub | 32.3467° N | 80.8900° W
9454755 | Bainbridge Point, Bainbridge Island, Prince William Sound, Alaska | Sub | 60.1967° N | 148.0420° W
PCT1116_1 | Baker Bay entrance, E of Sand Island Tower (Depth 23ft), Washington Current | Sub | 46.2620° N | 123.9980° W
8723073 | Bakers Haulover Inlet (inside), Florida | Sub | 25.9033° N | 80.1250° W
9410583 | Balboa Pier, Newport Beach, California | Sub | 33.6000° N | 117.9000° W
ACT6041_1 | Bald Eagle Pt., east of, Harris Creek, Choptank River, Maryland Current | Sub | 38.7292° N | 76.3050° W
8658901 | Bald Head, Cape Fear River, North Carolina | Sub | 33.8800° N | 78.0017° W
8728237 | Bald Point, Ochlockonee Bay, Apalachee Bay, Florida | Sub | 29.9483° N | 84.3417° W
PCT0046_1 | Ballast Point, 0.55 nmi. north of (Depth 14ft), San Diego Bay, California Current | Sub | 32.6958° N | 117.2325° W
PCT0046_2 | Ballast Point, 0.55 nmi. north of (Depth 34ft), San Diego Bay, California Current | Sub | 32.6958° N | 117.2325° W
PCT0041_1 | Ballast Point, 100 yards north of, San Diego Bay, California Current | Sub | 32.6833° N | 117.2333° W
9410155 | Ballast Point, California | Ref | 32.6867° N | 117.2330° W
8726639 | Ballast Point, Tampa, Florida | Ref | 27.8900° N | 82.4800° W
PCT0036_1 | Ballast Point, south of (Depth 5ft), San Diego Bay, California Current | Sub | 32.6845° N | 117.2322° W
8574680 | Baltimore (Fort McHenry), Maryland | Ref | 39.2667° N | 76.5783° W
ACT4996_1 | Baltimore Harbor Approach (off Sandy Point), Maryland Current | Ref | 39.0130° N | 76.3683° W
9432373 | Bandon, Coquille River, Oregon | Sub | 43.1200° N | 124.4130° W
9445133 | Bangor Wharf, Washington | Ref | 47.7483° N | 122.7270° W
9445133 | Bangor Wharf, Washington (sub) | Sub | 47.7483° N | 122.7270° W
8414612 | Bangor, Penobscot River, Maine | Ref | 44.7850° N | 68.7667° W
8414612 | Bangor, Penobscot River, Maine (sub) | Sub | 44.7850° N | 68.7667° W
TEC2865 | Bannermans Branch, Northeast River, Cape Fear River, North Carolina | Sub | 34.5833° N | 77.7667° W
ACT7796_1 | Bar Channel (Depth 12ft), St. Simons Sound, Georgia Current | Sub | 31.1050° N | 81.3383° W
8413320 | Bar Harbor, Frenchman Bay, Maine | Ref | 44.3922° N | 68.2043° W
8720218 | Bar Pilot Dock, St. Johns River, Florida | Ref | 30.3982° N | 81.4279° W
ACT7726_1 | Bar, Doboy Sound, Georgia Current | Sub | 31.3450° N | 81.2350° W
9451625 | Baranof, Warm Spring Bay, Alaska | Ref | 57.0883° N | 134.8250° W
9451625 | Baranof, Warm Spring Bay, Alaska (sub) | Sub | 57.0883° N | 134.8250° W
8761687 | Barataria Pass, Louisiana | Sub | 29.2750° N | 89.9450° W
8674251 | Barbour Island, Barbour Island River, Georgia | Sub | 31.5783° N | 81.2400° W
8770613 | Barbours Cut, Morgans Point, Galveston Bay, Texas | Ref | 29.6817° N | 94.9850° W
8770613 | Barbours Cut, Morgans Point, Galveston Bay, Texas (sub) | Sub | 29.6817° N | 94.9850° W
9452318 | Barlow Cove, Mansfield Peninsula, Lynn Canal, Alaska | Sub | 58.3217° N | 134.8780° W
9440483 | Barlow Point, Columbia River, Washington | Ref | 46.1522° N | 123.0392° W
8533615 | Barnegat Inlet, USCG Station, Barnegat Bay, New Jersey | Ref | 39.7617° N | 74.1117° W
8533141 | Barnegat Pier, Barnegat Bay, New Jersey | Sub | 39.9183° N | 74.1100° W
8447335 | Barnstable Harbor, Beach Point, Cape Cod Bay, Massachusetts | Sub | 41.7217° N | 70.2850° W
PCT2641_1 | Barren Island Light, 2 miles south from, Dixon Entrance, Alaska Current | Sub | 54.7000° N | 131.3500° W
8571579 | Barren Island, Chesapeake Bay, Maryland | Ref | 38.3417° N | 76.2650° W
8571579 | Barren Island, Chesapeake Bay, Maryland (sub) | Sub | 38.3417° N | 76.2650° W
8517394 | Barren Island, Rockaway Inlet, Jamaica Bay, New York | Sub | 40.5783° N | 73.8883° W
9446742 | Barron Point, Little Snookum Inlet Entrance, Puget Sound, Washington | Sub | 47.1567° N | 123.0080° W
9494935 | Barrow (offshore), Alaska | Ref | 71.3601° N | 156.7299° W
9499176 | Barter Island, Alaska | Ref | 70.1286° N | 143.6110° W
9452534 | Bartlett Cove, Glacier Bay, Alaska | Sub | 58.4567° N | 135.8830° W
9437581 | Barview, Tillamook Bay, Oregon | Sub | 45.5683° N | 123.9430° W
8413651 | Bass Harbor, Mount Desert Island, Maine | Sub | 44.2417° N | 68.3533° W
8761289 | Bastian Island, Louisiana | Sub | 29.2867° N | 89.6633° W
8417227 | Bath, Kennebec River, Maine | Ref | 43.9250° N | 69.8150° W
8417227 | Bath, Kennebec River, Maine (sub) | Sub | 43.9250° N | 69.8150° W
8668092 | Battery Creek, 4 mi. above entrance, Beaufort River, South Carolina | Sub | 32.4133° N | 80.7000° W
ACT6936_1 | Battery, southwest of, Ashley River, Charleston Harbor, South Carolina Current | Sub | 32.7672° N | 79.9338° W
8726689 | Bay Aristocrat Village, Old Tampa Bay, Florida | Sub | 27.9417° N | 82.7200° W
9440846 | Bay Center, Palix River, Willapa Bay, Washington | Sub | 46.6233° N | 123.9450° W
9441038 | Bay City, South Bay, Grays Harbor, Washington | Sub | 46.8617° N | 124.0600° W
TWC0865 | Bay City, Tillamook Bay, Oregon | Sub | 45.5167° N | 123.9000° W
8761108 | Bay Gardene, Louisiana | Sub | 29.5983° N | 89.6183° W
8516661 | Bay Park, East Rockaway, Hewlett Bay, New York | Ref | 40.6300° N | 73.6700° W
ACT7191_1 | Bay Point Island, S of, Broad River entrance (Depth 15ft), South Carolina Current | Sub | 32.2333° N | 80.6300° W
8729742 | Bay Point, Blackwater River, Pensacola Bay, Florida | Sub | 30.5717° N | 87.0050° W
8515102 | Bay Shore, Watchogue Creek Entrance, Great South Bay, New York | Sub | 40.7167° N | 73.2400° W
9414486 | Bay Slough, east end, San Francisco Bay, California | Sub | 37.5450° N | 122.2220° W
9414483 | Bay Slough, west end, San Francisco Bay, California | Sub | 37.5517° N | 122.2430° W
8453033 | Bay Spring, Bullock Cove, Narragansett Bay, Rhode Island | Sub | 41.7517° N | 71.3517° W
8747437 | Bay Waveland Yacht Club, Bay St. Louis, Mississippi | Ref | 30.3250° N | 89.3250° W
8747437 | Bay Waveland Yacht Club, Bay St. Louis, Mississippi (sub) | Sub | 30.3250° N | 89.3250° W
9461337 | Bay of Waterfalls, Adak Island, Alaska | Sub | 51.6417° N | 176.8250° W
8761473 | Bayou BonFouca, Route 433, Louisiana | Sub | 30.2717° N | 89.7933° W
8739803 | Bayou La Batre Bridge, Alabama | Ref | 30.4057° N | 88.2477° W
8739051 | Bayou La Batre, Mississippi Sound, Alabama | Sub | 30.3717° N | 88.2750° W
8743639 | Bayou Poito, Back Bay, Biloxi, Mississippi | Ref | 30.4383° N | 88.8450° W
TEC4455 | Bayou Rigaud, Grand Isle, Barataria Bay, Louisiana | Sub | 29.2667° N | 89.9667° W
8743301 | Bayou Talla, Back Bay, Biloxi, Mississippi | Ref | 30.4300° N | 88.8000° W
8727151 | Bayport, Florida | Ref | 28.5333° N | 82.6500° W
8636261 | Bayport, Rappahannock River, Virginia | Sub | 37.7550° N | 76.6733° W
8516299 | Bayville Bridge, Oyster Bay, New York | Ref | 40.9033° N | 73.5500° W
8516299 | Bayville Bridge, Oyster Bay, New York (sub) | Sub | 40.9033° N | 73.5500° W
8638867 | Bayville, Lynnhaven Bay, Virginia | Sub | 36.8933° N | 76.1050° W
8517137 | Beach Channel (bridge), Jamaica Bay, New York | Ref | 40.5883° N | 73.8200° W
8517137 | Beach Channel (bridge), Jamaica Bay, New York (sub) | Sub | 40.5883° N | 73.8200° W
8679945 | Beach Creek ent., Cumberland Island, Georgia | Sub | 30.7267° N | 81.4767° W
TEC3401 | Beach Hammock, Georgia | Sub | 31.9500° N | 80.9333° W
8534208 | Beach Haven Coast Guard Station, Little Egg Harbor, New Jersey | Sub | 39.5483° N | 74.2567° W
8534048 | Beach Haven Crest, Little Egg Harbor, New Jersey | Sub | 39.6133° N | 74.2100° W
9440079 | Beacon Rock State Park, Columbia River, Washington | Ref | 45.6203° N | 122.0203° W
8518934 | Beacon, Flushkill, Hudson River, New York | Ref | 41.5000° N | 73.9833° W
9451859 | Bear Bay, Alaska | Sub | 57.4183° N | 135.5830° W
9455128 | Bear Cove, Aialik Peninsula, Alaska | Sub | 59.8017° N | 149.6150° W
9455595 | Bear Cove, Kachemak Bay, Cook Inlet, Alaska | Ref | 59.7250° N | 151.0230° W
9455595 | Bear Cove, Kachemak Bay, Cook Inlet, Alaska (sub) | Sub | 59.7250° N | 151.0230° W
8672667 | Bear River, (Range 'A' Light), Georgia | Ref | 31.7933° N | 81.1817° W
8672667 | Bear River, (Range 'A' Light), Georgia (sub) | Sub | 31.7933° N | 81.1817° W
PCT3616_1 | Beauclerc Island Light, 1 mile east of, Sumner Strait, Alaska Current | Sub | 56.2500° N | 133.8167° W
ACT7236_1 | Beaufort Airport, Beaufort River (Depth 15ft), Port Royal Sound, South Carolina Current | Sub | 32.4500° N | 80.6633° W
8656569 | Beaufort Inlet Channel Range, North Carolina | Sub | 34.6983° N | 76.6650° W
ACT7226_1 | Beaufort River (Depth 15ft), Port Royal Sound, South Carolina Current | Sub | 32.4033° N | 80.6717° W
ACT7206_1 | Beaufort River Entrance (Depth 15ft), Port Royal Sound, South Carolina Current | Sub | 32.2883° N | 80.6517° W
ACT7231_1 | Beaufort, Beaufort River (Depth 12ft), Port Royal Sound, South Carolina Current | Sub | 32.4300° N | 80.6767° W
8667999 | Beaufort, Beaufort River, South Carolina | Ref | 32.4300° N | 80.6750° W
8656518 | Beaufort, Taylor Creek, North Carolina | Sub | 34.7117° N | 76.6450° W
9455304 | Beauty Bay, Nuka Bay, Alaska | Sub | 59.5267° N | 150.6280° W
9459522 | Beaver Bay, Alaska | Sub | 55.4733° N | 160.8400° W
8532715 | Beaverdam Creek entrance, Metedeconk River, New Jersey | Sub | 40.0617° N | 74.0617° W
8532716 | Beaverdam Creek, inside, Metedeconk River, New Jersey | Sub | 40.0617° N | 74.0733° W
ACT2201_1 | Beavertail Point, 0.8 mile northwest of, Narragansett Bay, Rhode Island Current | Sub | 41.4583° N | 71.4117° W
8453999 | Beavertail Point, Conanicut Island, Rhode Island | Sub | 41.4517° N | 71.4017° W
9410962 | Bechers Bay, Santa Rosa Island, California | Sub | 34.0083° N | 120.0470° W
9461582 | Bechevin Bay, Atka Island, Alaska | Sub | 52.0367° N | 175.1150° W
PCT5451_1 | Bechevin Bay, off Rocky Point, Isanotski Strait, Alaska Current | Sub | 54.9833° N | 163.4333° W
9450906 | Beck Island, Clarence Strait, Alaska | Sub | 56.0467° N | 132.8620° W
9451287 | Beecher Pass, Wrangell Narrows, Alaska | Ref | 56.5950° N | 132.9870° W
9451287 | Beecher Pass, Wrangell Narrows, Alaska (sub) | Sub | 56.5950° N | 132.9870° W
ACT6971_1 | Bees Ferry Bridge, Ashley River, Charleston Harbor, South Carolina Current | Sub | 32.8467° N | 80.0500° W
8534975 | Beesleys Point, Great Egg Harbor Bay, New Jersey | Sub | 39.2883° N | 74.6283° W
PCT2936_1 | Behm Narrows, Behm Canal, Alaska Current | Sub | 55.9137° N | 131.5320° W
8672462 | Belfast, Belfast River, Georgia | Sub | 31.8217° N | 81.2983° W
8415191 | Belfast, Penobscot Bay, Maine | Sub | 44.4267° N | 69.0050° W
8637072 | Belleville, Mobjack Bay, Virginia | Sub | 37.4117° N | 76.4383° W
8530591 | Belleville, Passaic River, New Jersey | Sub | 40.7867° N | 74.1467° W
8590111 | Bellevue, Potomac River, DC | Sub | 38.8267° N | 77.0267° W
9449211 | Bellingham, Bellingham Bay, Washington | Sub | 48.7450° N | 122.4950° W
8516211 | Bellmore, Bellmore Creek, Hempstead Bay, New York | Sub | 40.6633° N | 73.5200° W
8674638 | Bellville Point, Sapelo River, Georgia | Sub | 31.5317° N | 81.3600° W
8532337 | Belmar (ocean), New Jersey | Sub | 40.1850° N | 74.0083° W
TEC3531 | Below Spring Bluff, Little Satilla River, Georgia | Sub | 31.1667° N | 81.6167° W
8665567 | Ben Sawyer Bridge, ICWW, South Carolina | Sub | 32.7733° N | 79.8417° W
8579135 | Benedict, Patuxent River, Maryland | Sub | 38.5133° N | 76.6700° W
ACT5961_1 | Benedict, highway bridge, Patuxent River, Maryland Current | Sub | 38.5117° N | 76.6722° W
9415111 | Benicia, California | Sub | 38.0433° N | 122.1300° W
9751567 | Benner Bay, St. Thomas, Virgin Islands | Ref | 18.3200° N | 64.8700° W
8661989 | Bennet's Dock, Pawleys Island Creek, South Carolina | Ref | 33.4350° N | 79.1267° W
PCT3076_1 | Berg Bay, Alaska Current | Sub | 56.3437° N | 132.0077° W
ACT3951_2 | Bergen Point Reach (Bayonne Bridge) (Depth 29ft), Kill Van Kull, New York Current | Sub | 40.6417° N | 74.1433° W
ACT3951_1 | Bergen Point Reach (Bayonne Bridge), Kill van Kull, New York Current (16d) | Ref | 40.6417° N | 74.1433° W
8519483 | Bergen Point West Reach, Kill Van Kull, New York | Ref | 40.6367° N | 74.1417° W
9414816 | Berkeley, San Francisco Bay, California | Ref | 37.8650° N | 122.3070° W
9466477 | Bethel, Kuskokwim River, Alaska | Ref | 60.8000° N | 161.7500° W
9466477 | Bethel, Kuskokwim River, Alaska (sub) | Sub | 60.8000° N | 161.7500° W
PCT2651_1 | Between Dundas Island and Cape Fox, Dixon Entrance, Alaska Current | Sub | 54.7000° N | 130.8333° W
8418828 | Biddeford, Saco River, Maine | Ref | 43.4917° N | 70.4467° W
8418828 | Biddeford, Saco River, Maine (sub) | Sub | 43.4917° N | 70.4467° W
8536581 | Bidwell Creek entrance, Delaware Bay, New Jersey | Ref | 39.1283° N | 74.8917° W
8536581 | Bidwell Creek entrance, Delaware Bay, New Jersey (sub) | Sub | 39.1283° N | 74.8917° W
8536551 | Bidwell Creek, Route 47 bridge, Delaware Bay, New Jersey | Sub | 39.1183° N | 74.8683° W
9457321 | Big Bay, Shuyak Island, Alaska | Sub | 58.5550° N | 152.6130° W
8724489 | Big Coppitt Key, northeast side, Waltz Key Basin, Florida | Sub | 24.6017° N | 81.6550° W
8729909 | Big Lagoon, Florida | Ref | 30.3267° N | 87.3567° W
8664611 | Big Paradise Island, Wando River, South Carolina | Sub | 32.9150° N | 79.7467° W
8724193 | Big Pine Key, Bogie Channel Bridge, Florida | Sub | 24.6967° N | 81.3483° W
8724192 | Big Pine Key, Coupon Bight, Florida | Sub | 24.6517° N | 81.3500° W
8724201 | Big Pine Key, Doctors Arm, Bogie Channel, Florida | Sub | 24.6900° N | 81.3567° W
8724215 | Big Pine Key, Newfound Harbor Channel, Florida | Sub | 24.6517° N | 81.3750° W
8724211 | Big Pine Key, Pine Channel Bridge, north side, Florida | Sub | 24.6700° N | 81.3683° W
8724213 | Big Pine Key, Pine Channel Bridge, south side, Florida | Sub | 24.6683° N | 81.3717° W
8724178 | Big Pine Key, Spanish Harbor, Florida | Sub | 24.6483° N | 81.3300° W
8724231 | Big Pine Key, north end, Florida | Sub | 24.7450° N | 81.3950° W
8724226 | Big Pine Key, northeast shore, Florida | Sub | 24.7283° N | 81.3867° W
8724227 | Big Pine Key, west side, Pine Channel, Florida | Sub | 24.6900° N | 81.3833° W
9450623 | Big Salt Lake, Alaska | Ref | 55.6000° N | 132.9500° W
ACT8371_1 | Big Sarasota Pass, Sarasota Bay, Florida Current | Sub | 27.3000° N | 82.5633° W
8724246 | Big Spanish Key, Florida | Sub | 24.7883° N | 81.4117° W
8724274 | Big Torch Key, Harbor Channel, Florida | Sub | 24.7367° N | 81.4433° W
8724264 | Big Torch Key, Niles Channel, Florida | Sub | 24.7050° N | 81.4333° W
TPT2709 | Bikar (Dawson) Atoll, Marshall Islands | Sub | 12.2500° N | 170.1333° E
TPT2687 | Bikini Atoll, Marshall Islands | Sub | 11.6000° N | 165.5500° E
8538552 | Billingsport, New Jersey | Sub | 39.8500° N | 75.2500° W
8723439 | Billys Point, south of, Elliott Key, Biscayne Bay, Florida | Sub | 25.4150° N | 80.2100° W
8743735 | Biloxi (Cadet Point), Biloxi Bay, Mississippi | Ref | 30.3900° N | 88.8567° W
8743735 | Biloxi (Cadet Point), Biloxi Bay, Mississippi (sub) | Sub | 30.3900° N | 88.8567° W
8744934 | Biloxi River, lower end, Mississippi | Ref | 30.4350° N | 89.0083° W
8744117 | Biloxi, Biloxi Bay, Mississippi | Ref | 30.4117° N | 88.9033° W
8516055 | Biltmore Shores, South Oyster Bay, Long Island, New York | Sub | 40.6667° N | 73.4683° W
8720757 | Bings Landing, Matanzas River, ICWW, Florida | Ref | 29.6150° N | 81.2050° W
PCT4131_1 | Biorka Channel, Sitka Sound, Alaska Current | Sub | 56.8333° N | 135.5000° W
9462645 | Biorka Village, Biverly Inlet, Alaska | Ref | 53.8289° N | 166.2163° W
9462645 | Biorka Village, Biverly Inlet, Alaska (sub) | Sub | 53.8289° N | 166.2163° W
8410875 | Birch Islands, Cobscook Bay, Maine | Sub | 44.8750° N | 67.1583° W
9459251 | Bird Island, Shumagin Bank, Shumagin Islands, Alaska | Ref | 54.8352° N | 159.7596° W
8724436 | Bird Key, Similar Sound, Florida | Sub | 24.5883° N | 81.6383° W
ACT6391_1 | Bird Shoal, SE of (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.7005° N | 76.6538° W
8723089 | Biscayne Creek, ICWW, Florida | Sub | 25.8800° N | 80.1633° W
9415117 | Bishop Cut, Disappointment Slough, San Joaquin River, California | Sub | 38.0450° N | 121.4200° W
8571421 | Bishops Head, Hooper Strait, Maryland | Ref | 38.2204° N | 76.0387° W
8571421 | Bishops Head, Hooper Strait, Maryland (sub) | Sub | 38.2204° N | 76.0387° W
8535055 | Bivalve, Maurice River, Delaware Bay, New Jersey | Ref | 39.2325° N | 75.0328° W
8720434 | Black Creek, S.C.L. RR. bridge, Florida | Ref | 30.0800° N | 81.7617° W
ACT2071_1 | Black Point, SW of, Sakonnet River (Depth 15ft), Narragansett Bay, Rhode Island Current | Sub | 41.5067° N | 71.2200° W
8661686 | Black River (south of Dunbar), Great Pee Dee River, South Carolina | Sub | 33.5117° N | 79.3417° W
8467373 | Black Rock Harbor, Cedar Creek, Connecticut | Ref | 41.1567° N | 73.2133° W
9465182 | Black Rock, Walrus Islands, Nushagak Bay, Alaska | Ref | 58.7083° N | 160.1880° W
9465182 | Black Rock, Walrus Islands, Nushagak Bay, Alaska (sub) | Sub | 58.7083° N | 160.1880° W
8674962 | Blackbeard Creek, Blackbeard Island, Georgia | Sub | 31.4883° N | 81.2100° W
TEC3463 | Blackbeard Island, Georgia | Sub | 31.5333° N | 81.2000° W
ACT8356_1 | Blackburn Bay, south end, bridge, Florida Current | Sub | 27.1233° N | 82.4700° W
9415021 | Blackslough Landing, San Joaquin River, California | Ref | 37.9947° N | 121.4190° W
9415021 | Blackslough Landing, San Joaquin River, California (sub) | Sub | 37.9947° N | 121.4190° W
8579997 | Bladensburg, Anacostia River, Maryland | Ref | 38.9333° N | 76.9383° W
8579997 | Bladensburg, Anacostia River, Maryland (sub) | Sub | 38.9333° N | 76.9383° W
PCT2686_1 | Blaine Point, Pearse Canal, Alaska Current | Sub | 55.0333° N | 130.2167° W
ACT6306_1 | Blair Channel (Depth 10ft), Ocracoke Inlet, Pamlico Sound, North Carolina Current | Sub | 35.0813° N | 76.0338° W
PCT3071_1 | Blake Island, Alaska Current | Sub | 56.2230° N | 131.9088° W
9415396 | Blakes Landing, Tomales Bay, California | Sub | 38.1900° N | 122.9170° W
PCT3061_1 | Blanche Rock, Ernest Sound, Alaska Current | Sub | 56.0833° N | 132.0833° W
PCT2911_1 | Blank Point, Nichols Passage, Alaska Current | Sub | 55.2487° N | 131.6693° W
PCT3681_1 | Blaquiere Point, 1 mile SSW of, Sumner Strait, Alaska Current | Sub | 56.5500° N | 132.5667° W
9450973 | Blashke Island, Clarence Strait, Alaska | Sub | 56.1267° N | 132.8950° W
8663781 | Blessing Plantation, East Branch, Cooper River, South Carolina | Sub | 33.0550° N | 79.8800° W
ACT8621_1 | Blind Pass (north end), Florida Current | Sub | 27.7567° N | 82.7617° W
8459338 | Block Island (Old Harbor), Rhode Island | Ref | 41.1733° N | 71.5567° W
8459338 | Block Island (Old Harbor), Rhode Island (sub) | Sub | 41.1733° N | 71.5567° W
8459681 | Block Island (SW end), Block Island Sound, Rhode Island | Ref | 41.1633° N | 71.6100° W
8459681 | Block Island (SW end), Block Island Sound, Rhode Island (sub) | Sub | 41.1633° N | 71.6100° W
9450406 | Block Island, Tlevak Strait, Alaska | Sub | 55.2633° N | 133.1150° W
ACT4956_1 | Bloody Point Bar Light, 0.6 mi. NW of (Depth 19ft), Chesapeake Bay, Maryland Current | Sub | 38.8395° N | 76.4028° W
8669801 | Bloody Point, Daufuskie Island, New River, South Carolina | Sub | 32.0817° N | 80.8783° W
ACT7316_1 | Bloody Pt., 0.5 mile north of, New River, South Carolina Current | Sub | 32.0883° N | 80.8800° W
ACT7321_1 | Bloody Pt., 0.5 mile west of, New River, South Carolina Current | Sub | 32.0817° N | 80.8833° W
8720203 | Blount Island Bridge, Florida | Sub | 30.4133° N | 81.5450° W
8729941 | Blue Angels Park, Perdido Bay, Florida | Ref | 30.3869° N | 87.4288° W
8414112 | Blue Hill Harbor, Blue Hill Bay, Maine | Sub | 44.4083° N | 68.5633° W
8667201 | Bluff Islands, Ashepoo River, South Carolina | Sub | 32.5783° N | 80.4933° W
8666359 | Bluff Plantation, Combahee River, South Carolina | Sub | 32.6833° N | 80.7383° W
8666699 | Bluff Point, Wadmalaw River, South Carolina | Sub | 32.6467° N | 80.2567° W
8669103 | Bluffton, May River, South Carolina | Sub | 32.2300° N | 80.8617° W
PCT3791_1 | Blunt Point, Wrangell Narrows, Alaska Current | Sub | 56.7783° N | 132.9793° W
PCT3211_1 | Boat Rocks, 2 miles west of, Cordova Bay, Alaska Current | Sub | 54.8167° N | 132.5667° W
8724503 | Boca Chica Channel Bridge, Florida | Sub | 24.5767° N | 81.7217° W
8724485 | Boca Chica Key, Long Point, Florida | Sub | 24.6033° N | 81.6983° W
8724499 | Boca Chica Key, Southwest end, Florida | Sub | 24.5633° N | 81.7133° W
8724493 | Boca Chica Marina, Florida | Ref | 24.5750° N | 81.7083° W
ACT8316_1 | Boca Grande Pass, Charlotte Harbor, Florida Current | Sub | 26.7143° N | 82.2567° W
8722816 | Boca Raton, Lake Boca Raton, Florida | Ref | 26.3433° N | 80.0767° W
9450305 | Boca de Quadra, Revillagigedo Channel, Alaska | Sub | 55.1167° N | 130.7980° W
9415625 | Bodega Harbor entrance, California | Sub | 38.3083° N | 123.0550° W
ACT6271_2 | Bodie Island-Pea Island, between (Depth 12ft), Oregon Inlet, North Carolina Current | Sub | 35.7767° N | 75.5350° W
ACT6271_1 | Bodie Island-Pea Island, between (Depth 6ft), Oregon Inlet, North Carolina Current | Sub | 35.7767° N | 75.5350° W
8720084 | Boggy Creek, 2 mi. above entrance, Nassau River, Florida | Sub | 30.5883° N | 81.6633° W
9462444 | Bogoslof Island, Aleutian Islands, Alaska | Sub | 53.9300° N | 168.0330° W
TEC2837 | Bogue Inlet, North Carolina | Sub | 34.6500° N | 77.1000° W
8725541 | Bokellia, Charlotte Harbor, Florida | Ref | 26.7067° N | 82.1633° W
9414958 | Bolinas, Bolinas Lagoon, California | Ref | 37.9078° N | 122.6786° W
9414958 | Bolinas, Bolinas Lagoon, California (sub) | Sub | 37.9078° N | 122.6786° W
ACT8856_3 | Bolivar Roads (Depth 31ft), Galveston Bay, Texas Current | Sub | 29.3433° N | 94.7813° W
ACT8856_1 | Bolivar Roads (Depth 8ft), Galveston Bay, Texas Current | Sub | 29.3433° N | 94.7813° W
ACT8856_2 | Bolivar Roads, Texas Current (14d) | Ref | 29.3433° N | 94.7813° W
8731952 | Bon Secour, Bon Secour River, Alabama | Sub | 30.3033° N | 87.7350° W
8663731 | Bonneau Ferry, East Branch, Cooper River, South Carolina | Sub | 33.0717° N | 79.8833° W
ACT6896_1 | Bonneau Ferry, east of, Cooper River, Charleston Harbor, South Carolina Current | Sub | 33.0717° N | 79.8833° W
9461391 | Boot Bay, Adak Island, Alaska | Sub | 51.7133° N | 176.5300° W
8723971 | Boot Key Harbor bridge, Boot Key, Florida | Sub | 24.7033° N | 81.1050° W
8416828 | Boothbay Harbor, Maine | Sub | 43.8500° N | 69.6283° W
9414835 | Borden Highway Bridge, Middle River, San Joaquin River, California | Sub | 37.8917° N | 121.4880° W
9414836 | Borden Highway Bridge, Old River, San Joaquin River, California | Sub | 37.8833° N | 121.5770° W
9414367 | Borden Highway Bridge, San Joaquin River, San Joaquin River, California | Sub | 37.9367° N | 121.3333° W
PCT2661_1 | Boston Islands, 1 mile south from, Dixon Entrance, Alaska Current | Sub | 54.6833° N | 130.5667° W
8444162 | Boston Light, Boston Harbor, Massachusetts | Ref | 42.3283° N | 70.8917° W
8444162 | Boston Light, Boston Harbor, Massachusetts (sub) | Sub | 42.3283° N | 70.8917° W
8443970 | Boston, Boston Harbor, Massachusetts | Ref | 42.3539° N | 71.0503° W
9751774 | Botany Bay, St. Thomas, Virgin Islands | Ref | 18.3633° N | 65.0350° W
8417391 | Bowdoinham, Cathance River, Kennebec River, Maine | Sub | 44.0083° N | 69.8950° W
8667272 | Bowles Island, New Chehaw River, Combahee River, South Carolina | Sub | 32.5650° N | 80.5167° W
8722472 | Boy Scout Dock, Loxahatchee River, Florida | Sub | 26.9867° N | 80.1417° W
8722706 | Boynton Beach, Lake Worth, Florida | Ref | 26.5483° N | 80.0533° W
8722706 | Boynton Beach, Lake Worth, Florida (sub) | Sub | 26.5483° N | 80.0533° W
8669625 | Braddock Point, Hilton Head Island, South Carolina | Sub | 32.1133° N | 80.8300° W
ACT7286_1 | Braddock Point, SW of, Calibogue Sound (Depth 10ft), South Carolina Current | Sub | 32.1050° N | 80.8367° W
8726247 | Bradenton, Manatee River, Florida | Sub | 27.5000° N | 82.5733° W
9451012 | Bradfield Canal, Alaska | Ref | 56.1833° N | 131.5720° W
9451012 | Bradfield Canal, Alaska (sub) | Sub | 56.1833° N | 131.5720° W
8672455 | Bradley Point, Bradley River, Georgia | Sub | 31.8217° N | 81.0500° W
ACT7576_1 | Bradley Point, NNE of (Depth 10ft), Ossabaw Sound, Georgia Current | Sub | 31.8317° N | 81.0383° W
8555889 | Brandywine Shoal Light, Delaware Bay, New Jersey | Ref | 38.9867° N | 75.1133° W
8555889 | Brandywine Shoal Light, Delaware Bay, New Jersey (sub) | Sub | 38.9867° N | 75.1133° W
8465233 | Branford, Branford River, Connecticut | Sub | 41.2617° N | 72.8183° W
8446009 | Brant Rock, Green Harbor River, Massachusetts | Ref | 42.0833° N | 70.6467° W
8446009 | Brant Rock, Green Harbor River, Massachusetts (sub) | Sub | 42.0833° N | 70.6467° W
9415446 | Brazos Drawbridge, Napa River, California | Sub | 38.2100° N | 122.3070° W
8665552 | Breach Inlet, Isle of Palms, South Carolina | Sub | 32.7767° N | 79.8117° W
9445958 | Bremerton, Sinclair Inlet, Port Orchard, Puget Sound, Washington | Ref | 47.5617° N | 122.6230° W
ACT2096_1 | Brenton Point, 1.4 n.mi. southwest of (Depth 7ft), Narragansett Bay, Rhode Island Current | Sub | 41.4317° N | 71.3767° W
8760595 | Breton Islands, Louisiana | Sub | 29.4933° N | 89.1733° W
8575331 | Brewer Point, Severn River, Maryland | Sub | 39.0267° N | 76.5333° W
ACT5051_1 | Brewerton Channel Eastern Ext., Buoy '7' (Depth 14ft), Chesapeake Bay, Maryland Current | Sub | 39.1630° N | 76.3897° W
8667199 | Briars Creek ent., Wimbee Creek, Bull River, Coosaw River, South Carolina | Sub | 32.5783° N | 80.6700° W
ACT7241_1 | Brickyard Creek (Depth 10ft), Port Royal Sound, South Carolina Current | Sub | 32.4733° N | 80.6917° W
8667017 | Brickyard Ferry, swing bridge, Ashepoo River, South Carolina | Sub | 32.6133° N | 80.4817° W
8667624 | Brickyard Point, Brickyard Creek, Coosaw River, South Carolina | Sub | 32.4933° N | 80.6850° W
8546252 | Bridesburg, Philadelphia, Pennsylvania | Ref | 39.9833° N | 75.0750° W
8546252 | Bridesburg, Philadelphia, Pennsylvania (sub) | Sub | 39.9833° N | 75.0750° W
ACT8611_1 | Bridge, 0.8 mi. south of Maximo Pt., Florida Current | Sub | 27.6933° N | 82.6800° W
8538921 | Bridgeboro, Rancocas Creek, New Jersey | Sub | 40.0283° N | 74.9317° W
8467150 | Bridgeport Harbor, Bridgeport, Connecticut | Ref | 41.1758° N | 73.1840° W
8538449 | Bridgeport, Raccoon Creek, New Jersey | Sub | 39.8067° N | 75.3550° W
8532585 | Brielle, Route 35 bridge, Manasquan River, New Jersey | Sub | 40.1050° N | 74.0550° W
8534496 | Brigantine Channel @ Hoffman Thorofare, New Jersey | Sub | 39.4350° N | 74.3633° W
9437815 | Brighton, Nehalem River, Oregon | Sub | 45.6700° N | 123.9250° W
8451552 | Bristol Ferry, Narragansett Bay, Rhode Island | Ref | 41.6367° N | 71.2550° W
8451552 | Bristol Ferry, Narragansett Bay, Rhode Island (sub) | Sub | 41.6367° N | 71.2550° W
8452154 | Bristol Highlands, Narragansett Bay, Rhode Island | Ref | 41.6967° N | 71.2933° W
8451929 | Bristol, Bristol Harbor, Narragansett Bay, Rhode Island | Sub | 41.6683° N | 71.2800° W
8638923 | Broad Bay Canal, Lynnhaven Bay, Virginia | Sub | 36.9017° N | 76.0617° W
9462676 | Broad Bight, Akutan Island, Aleutian Islands, Alaska | Ref | 54.0646° N | 165.9371° W
8669338 | Broad Creek, Hilton Head Island, South Carolina | Sub | 32.1850° N | 80.7533° W
ACT7271_1 | Broad River Bridge, S of, Broad River (Depth 15ft), South Carolina Current | Sub | 32.3817° N | 80.7767° W
ACT7196_1 | Broad River Entrance, Point Royal Sound (Depth 15ft), South Carolina Current | Sub | 32.2317° N | 80.6400° W
ACT3506_1 | Broadway Bridge, Harlem River, New York Current | Sub | 40.8733° N | 73.9117° W
PCT3481_1 | Brockman Island, east of, El Capitan Passage, Alaska Current | Sub | 55.9668° N | 133.3048° W
ACT1736_1 | Broken Ground-Horseshoe Shoal, between, Nantucket Sound, Massachusetts Current | Sub | 41.5500° N | 70.2850° W
ACT3346_1 | Bronx-Whitestone Bridge, East of (Depth 14ft), East River, New York Current | Sub | 40.8017° N | 73.8267° W
9430104 | Brookings, Chetco Cove, Oregon | Sub | 42.0433° N | 124.2850° W
ACT3461_1 | Brooklyn Bridge, 0.1 mile southwest of, East River, New York Current | Sub | 40.7033° N | 74.0000° W
8517847 | Brooklyn Bridge, East River, New York | Ref | 40.7033° N | 73.9950° W
8517847 | Brooklyn Bridge, East River, New York (sub) | Sub | 40.7033° N | 73.9950° W
ACT5951_1 | Broomes Island, 0.4 mile south of, Patuxent River, Maryland Current | Sub | 38.3950° N | 76.5542° W
8577123 | Broomes Island, Patuxent River, Maryland | Sub | 38.4150° N | 76.5450° W
ACT7791_1 | Broughton Island (south) (Depth 9ft), Buttermilk Sound, Altamaha Sound, Georgia Current | Sub | 31.3100° N | 81.4133° W
8668109 | Broughton Point, Hazzard Creek, Broad River, South Carolina | Sub | 32.4100° N | 80.8850° W
TWC1659 | Brown Cove, Frederick Sound, Alaska | Sub | 56.8833° N | 132.8000° W
8638922 | Brown Cove, Lynnhaven Bay, Virginia | Sub | 36.8750° N | 76.0617° W
TEC3001 | Brown Island, South Santee River, South Carolina | Sub | 33.1500° N | 79.3333° W
8637444 | Browns Bay, Mobjack Bay, Virginia | Sub | 37.3000° N | 76.4000° W
9445832 | Brownsville, Port Orchard, Puget Sound, Washington | Sub | 47.6517° N | 122.6150° W
ACT7826_1 | Brunswick River Bridge, southeast of (Depth 13ft), St. Simons Sound, Georgia Current | Sub | 31.1150° N | 81.4767° W
ACT7826_2 | Brunswick River Bridge, southeast of (Depth 21ft), St. Simons Sound, Georgia Current | Sub | 31.1150° N | 81.4767° W
ACT7821_1 | Brunswick River, off Quarantine Dock, St. Simons Sound, Georgia Current | Sub | 31.1117° N | 81.4733° W
8417527 | Brunswick, Androscoggin River, Kennebec River, Maine | Sub | 43.9217° N | 69.9633° W
ACT7831_1 | Brunswick, off Prince Street Dock, St. Simons Sound, Georgia Current | Sub | 31.1383° N | 81.4967° W
8638854 | Buchanan Creek entrance, Lynnhaven Bay, Virginia | Sub | 36.8617° N | 76.1150° W
8663858 | Buck Hall, Awendaw Creek, Bulls Bay, South Carolina | Sub | 33.0400° N | 79.5600° W
9418778 | Bucksport, Humboldt Bay, California | Sub | 40.7783° N | 124.1970° W
8414684 | Bucksport, Penobscot River, Maine | Sub | 44.5717° N | 68.8017° W
8661139 | Bucksport, Waccamaw River, South Carolina | Ref | 33.6467° N | 79.0950° W
9446807 | Budd Inlet, south of Gull Harbor, Washington | Ref | 47.0983° N | 122.8950° W
8720767 | Buffalo Bluff, St. Johns River, Florida | Ref | 29.5950° N | 81.6817° W
8720767 | Buffalo Bluff, St. Johns River, Florida (sub) | Sub | 29.5950° N | 81.6817° W
8676787 | Buffalo River entrance, Turtle River, Georgia | Sub | 31.2150° N | 81.5833° W
9461467 | Bugle Point, Great Sitkin Island, Aleutian Islands, Alaska | Sub | 52.0383° N | 175.9800° W
8767961 | Bulk Terminal, Louisiana | Ref | 30.1902° N | 93.3008° W
8661347 | Bull Creek entrance, Waccamaw River, South Carolina | Sub | 33.5967° N | 79.0983° W
8669414 | Bull Creek, Bull Island South, Cooper River, South Carolina | Sub | 32.1650° N | 80.8567° W
8669262 | Bull Island North, May River, South Carolina | Sub | 32.2000° N | 80.8150° W
ACT2106_1 | Bull Point, east of (Depth 10ft), Narragansett Bay, Rhode Island Current | Sub | 41.4800° N | 71.3500° W
ACT7461_1 | Bull River, 2 miles below hwy. bridge, Wassaw Sound, Georgia Current | Sub | 32.0183° N | 80.9400° W
ACT8446_1 | Bunces Pass (West of Bayway bridge), Tampa Bay, Florida Current | Sub | 27.6470° N | 82.7395° W
8570691 | Buntings Bridge, Chincoteague Bay, Maryland | Ref | 38.1389° N | 75.1835° W
ACT6926_1 | Buoy '19', off Nowell Creek, Wando River, Charleston Harbor, South Carolina Current | Sub | 32.8720° N | 79.8655° W
8539094 | Burlington, Delaware River, New Jersey | Ref | 40.0800° N | 74.8733° W
8539094 | Burlington, Delaware River, New Jersey (sub) | Sub | 40.0800° N | 74.8733° W
TWC1113 | Burns Point, Totten Inlet, Puget Sound, Washington | Sub | 47.1217° N | 123.0567° W
ACT7546_1 | Burnside Island, SE of, Burnside River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 31.9217° N | 81.0800° W
8413857 | Burnt Coat Harbor, Swans Island, Maine | Sub | 44.1450° N | 68.4500° W
TEC3541 | Burnt Fort, Satilla River, Georgia | Sub | 30.9500° N | 81.9000° W
8416028 | Burnt Island, Georges Islands, Maine | Sub | 43.8717° N | 69.2950° W
ACT7521_1 | Burntpot Island, west of, Skidaway River (Depth 6ft), Wassaw Sound, Georgia Current | Sub | 31.9683° N | 81.0533° W
9450914 | Burrough Bay, Behm Canal, Alaska | Ref | 56.0383° N | 131.0950° W
9448683 | Burrows Bay (Allan Island), Washington | Sub | 48.4600° N | 122.6950° W
9446254 | Burton, Quartermaster Hbr. (inside), Vashon I., Puget Sound, Washington | Sub | 47.3950° N | 122.4630° W
8638421 | Burwell Bay, James River, Virginia | Ref | 37.0567° N | 76.6683° W
8638421 | Burwell Bay, James River, Virginia (sub) | Sub | 37.0567° N | 76.6683° W
9454374 | Busby Island, Valdez Arm, Alaska | Sub | 60.8983° N | 146.7820° W
9447854 | Bush Point, Whidbey Island, Admiralty Inlet, Washington | Sub | 48.0333° N | 122.6070° W
ACT6196_1 | Bush River, 0.4 mi. SW of Bush Point, Maryland Current | Sub | 39.3567° N | 76.2567° W
9451074 | Bushy Island, Snow Passage, Alaska | Ref | 56.2767° N | 132.9850° W
9451074 | Bushy Island, Snow Passage, Alaska (sub) | Sub | 56.2767° N | 132.9850° W
ACT6576_1 | Butler Island, 0.3 mile south of, Winyah Bay, South Carolina Current | Sub | 33.4167° N | 79.2120° W
ACT7766_1 | Buzzard Roost Creek (Depth 13ft), Doboy Sound, Georgia Current | Sub | 31.4150° N | 81.3750° W
ACT7276_1 | Byrd Creek Entrance, SE of, Broad River (Depth 12ft), South Carolina Current | Sub | 32.4567° N | 80.8183° W
8726667 | CSX Rockport, Mckay Bay Entrance, Florida | Ref | 27.9133° N | 82.4250° W
8726667 | CSX Rockport, Mckay Bay Entrance, Florida (sub) | Sub | 27.9133° N | 82.4250° W
ACT7861_1 | Cabin Bluff, Cumberland River, St. Andrews Sound, Georgia Current | Sub | 30.8817° N | 81.5133° W
PCT3331_1 | Cabras Islands, 1 mile west of, Alaska Current | Sub | 55.3500° N | 133.4167° W
9410650 | Cabrillo Beach, California | Sub | 33.7067° N | 118.2730° W
8763206 | Caillou Boca, Louisiana | Sub | 29.0633° N | 90.8067° W
8664545 | Cainhoy, Wando River, South Carolina | Ref | 32.9267° N | 79.8300° W
8664545 | Cainhoy, Wando River, South Carolina (sub) | Sub | 32.9267° N | 79.8300° W
9414539 | Calaveras Point, west of, San Francisco Bay, California | Sub | 37.4667° N | 122.0670° W
8768094 | Calcasieu Pass, East Jetty, Louisiana | Ref | 29.7682° N | 93.3429° W
8669464 | Calibogue Cay, Broad Creek, Hilton Head Island, South Carolina | Sub | 32.1533° N | 80.7950° W
8668636 | Callawassie Creek, Colleton River, South Carolina | Sub | 32.3167° N | 80.8417° W
8668511 | Callawassie Island Bridge, Colleton River, South Carolina | Sub | 32.3417° N | 80.8567° W
8668655 | Callawassie Island, south, Colleton River, South Carolina | Sub | 32.3133° N | 80.8600° W
ACT6006_1 | Cambridge hwy. bridge, W. of Swing Span (Depth 18ft), Choptank River, Maryland Current | Sub | 38.5797° N | 76.0612° W
8571892 | Cambridge, Choptank River, Maryland | Ref | 38.5742° N | 76.0722° W
8571892 | Cambridge, Choptank River, Maryland (sub) | Sub | 38.5742° N | 76.0722° W
8761826 | Caminada Pass (bridge), Louisiana | Ref | 29.2100° N | 90.0400° W
9455151 | Camp Cove, Harris Peninsula, Alaska | Ref | 59.6933° N | 149.7480° W
9455151 | Camp Cove, Harris Peninsula, Alaska (sub) | Sub | 59.6933° N | 149.7480° W
8418606 | Camp Ellis, Saco River Entrance, Maine | Ref | 43.4617° N | 70.3817° W
8418606 | Camp Ellis, Saco River Entrance, Maine (sub) | Sub | 43.4617° N | 70.3817° W
PCT2721_1 | Camp Point, Portland Canal, Alaska Current | Sub | 55.2833° N | 129.9833° W
8665257 | Canaday Landing, south of, Edisto River, South Edisto River, South Carolina | Sub | 32.8133° N | 80.4067° W
8517381 | Canarsie, Jamaica Bay, New York | Sub | 40.6300° N | 73.8850° W
8721608 | Canaveral Harbor Entrance, Florida | Ref | 28.4083° N | 80.6017° W
TEC3427 | Cane Patch Creek entrance, Georgia | Sub | 31.8167° N | 81.1500° W
9451781 | Cannery Cove, Pybus Bay, Frederick Sound, Alaska | Sub | 57.3067° N | 134.1330° W
9452649 | Canoe Cove, North Pass, Lisianski Strait and Inlet, Alaska | Sub | 57.8467° N | 136.4220° W
8721804 | Canova Beach, Florida | Sub | 28.1383° N | 80.5783° W
8537562 | Canton, Stow Creek, Delaware River, New Jersey | Sub | 39.4617° N | 75.4033° W
PCT3316_1 | Cape Bartolome, 2 miles east of, Alaska Current | Sub | 55.2333° N | 133.5500° W
TEC3693 | Cape Canaveral, Florida | Sub | 28.4333° N | 80.5667° W
8632366 | Cape Charles Harbor (USCG Wharf), Chesapeake Bay, Virginia | Ref | 37.2633° N | 76.0200° W
8632366 | Cape Charles Harbor (USCG Wharf), Chesapeake Bay, Virginia (sub) | Sub | 37.2633° N | 76.0200° W
9461276 | Cape Chlanak, Kanaga Island, Alaska | Sub | 51.7100° N | 177.1450° W
9462941 | Cape Chunak, Unimak Island, Alaska | Ref | 55.0643° N | 163.5342° W
9461183 | Cape Chunu, Kanaga Island, Alaska | Sub | 51.6650° N | 177.6370° W
8447173 | Cape Cod Canal (Sta. 115), Sagamore, Cape Cod Bay, Massachusetts | Ref | 41.7750° N | 70.5350° W
8447173 | Cape Cod Canal (Sta. 115), Sagamore, Cape Cod Bay, Massachusetts (sub) | Sub | 41.7750° N | 70.5350° W
8447191 | Cape Cod Canal (Sta. 200), Bournedale, Cape Cod Bay, Massachusetts | Ref | 41.7700° N | 70.5617° W
8447191 | Cape Cod Canal (Sta. 200), Bournedale, Cape Cod Bay, Massachusetts (sub) | Sub | 41.7700° N | 70.5617° W
8447259 | Cape Cod Canal (Sta. 320), Bourne Bridge, Cape Cod Bay, Massachusetts | Ref | 41.7450° N | 70.5933° W
8447259 | Cape Cod Canal (Sta. 320), Bourne Bridge, Cape Cod Bay, Massachusetts (sub) | Sub | 41.7450° N | 70.5933° W
8447270 | Cape Cod Canal, RR. bridge, Buzzards Bay, Massachusetts | Ref | 41.7417° N | 70.6167° W
8447270 | Cape Cod Canal, RR. bridge, Buzzards Bay, Massachusetts (sub) | Sub | 41.7417° N | 70.6167° W
8447180 | Cape Cod Canal, Sandwich, Cape Cod Bay, Massachusetts | Ref | 41.7717° N | 70.5067° W
8447180 | Cape Cod Canal, Sandwich, Cape Cod Bay, Massachusetts (sub) | Sub | 41.7717° N | 70.5067° W
PCT5791_1 | Cape Constantine, 4 miles Southeast of, Alaska Current | Sub | 58.3333° N | 158.7667° W
9464961 | Cape Constantine, Nushagak Peninsula, Alaska | Ref | 58.5217° N | 159.1520° W
8725451 | Cape Coral Bridge, Caloosahatchee River, Florida | Sub | 26.5633° N | 81.9333° W
9440581 | Cape Disappointment, Washington | Ref | 46.3000° N | 124.0000° W
9490096 | Cape Espenberg, Kotzebue Sound, Alaska | Ref | 66.5857° N | 164.2508° W
TEC2847 | Cape Fear, North Carolina | Sub | 33.8500° N | 77.9667° W
PCT3336_1 | Cape Flores, 1 mile north of, Alaska Current | Sub | 55.3667° N | 133.3000° W
PCT3301_1 | Cape Flores, Ulloa Channel, Alaska Current | Sub | 55.3500° N | 133.3167° W
8654400 | Cape Hatteras (fishing pier), North Carolina | Ref | 35.2233° N | 75.6350° W
TEC2789 | Cape Hatteras, North Carolina | Sub | 35.2333° N | 75.5167° W
ACT8331_1 | Cape Haze, 2.3 mi. S of, Charlotte Hbr, Florida Current | Sub | 26.7450° N | 82.1517° W
8638999 | Cape Henry, Virginia | Sub | 36.9300° N | 76.0067° W
9454329 | Cape Hinchinbrook, Hinchinbrook Island, Alaska | Sub | 60.2383° N | 146.6480° W
9440482 | Cape Horn, Columbia River, Washington | Ref | 46.1517° N | 123.2900° W
8535902 | Cape Island Creek, Cape May, New Jersey | Sub | 38.9467° N | 74.9133° W
9455711 | Cape Kasilof, Cook Inlet, Alaska | Ref | 60.3367° N | 151.3800° W
9490571 | Cape Krusenstern, Kotzebue Sound, Alaska | Ref | 67.0542° N | 163.3213° W
PCT5741_1 | Cape Lieskof, 3 miles west of, Aleutian Islands, Alaska Current | Sub | 55.7500° N | 162.2000° W
8656937 | Cape Lookout (ocean), North Carolina | Sub | 34.6083° N | 76.5283° W
8656841 | Cape Lookout Bight, North Carolina | Ref | 34.6133° N | 76.5383° W
8535962 | Cape May (ocean), New Jersey | Sub | 38.9300° N | 74.9350° W
8536110 | Cape May Canal, Cape May, Delaware Bay, New Jersey | Ref | 38.9678° N | 74.9597° W
8536110 | Cape May Canal, Cape May, Delaware Bay, New Jersey (sub) | Sub | 38.9678° N | 74.9597° W
8535901 | Cape May Harbor, Cape May Inlet, New Jersey | Sub | 38.9483° N | 74.8917° W
8536021 | Cape May Point, Sunset Beach, Delaware Bay, New Jersey | Sub | 38.9467° N | 74.9717° W
9462838 | Cape Mordvinof, Unimak Island, Alaska | Sub | 54.9283° N | 164.4670° W
PCT2621_1 | Cape Muzon, 4 miles south from, Dixon Entrance, Alaska Current | Sub | 54.6000° N | 132.6833° W
PCT3196_1 | Cape Muzon, 5 miles east of, Cordova Bay, Alaska Current | Sub | 54.6667° N | 132.5333° W
8419399 | Cape Neddick, Maine | Sub | 43.1667° N | 70.5933° W
TWC1979 | Cape Ninilchik, Cook Inlet, Alaska | Sub | 60.0167° N | 151.7167° W
PCT4061_1 | Cape Ommaney Light, 5 miles east of, Chatham Strait, Alaska Current | Sub | 56.1667° N | 134.5167° W
ACT1771_1 | Cape Poge Light, 1.4 miles west of, Nantucket Sound, Massachusetts Current | Sub | 41.4242° N | 70.4833° W
ACT1721_1 | Cape Poge Lt., 1.7 miles SSE of, Nantucket Sound, Massachusetts Current | Sub | 41.4000° N | 70.4267° W
ACT1731_1 | Cape Poge Lt., 3.2 miles northeast of, Nantucket Sound, Massachusetts Current | Sub | 41.4583° N | 70.4000° W
8418772 | Cape Porpoise, Maine | Sub | 43.3667° N | 70.4317° W
TEC3011 | Cape Romain, 46 miles east of, South Carolina | Sub | 33.1000° N | 78.4333° W
8663101 | Cape Romain, South Carolina | Sub | 33.0250° N | 79.3483° W
8724947 | Cape Romano, Florida | Sub | 25.8533° N | 81.6750° W
TEC4165 | Cape Sable, East Cape, Florida | Sub | 25.1167° N | 81.0833° W
9462331 | Cape Sagak, Umnak Island, Alaska | Sub | 52.8417° N | 169.0430° W
9462787 | Cape Sarichef, Unimak Island, Alaska | Ref | 54.6000° N | 164.9280° W
9462787 | Cape Sarichef, Unimak Island, Alaska (sub) | Sub | 54.6000° N | 164.9280° W
9461704 | Cape Utalug (4 miles west of), Atka Island, Alaska | Sub | 52.1183° N | 174.2070° W
8668255 | Capers Creek, Cowen Creek, St. Helena Island, Beaufort River, South Carolina | Sub | 32.3717° N | 80.6050° W
8664941 | Capers Creek, South Capers Island, South Carolina | Ref | 32.8567° N | 79.7067° W
8664941 | Capers Creek, South Capers Island, South Carolina (sub) | Sub | 32.8567° N | 79.7067° W
8668837 | Capers Island, Trenchards Inlet, South Carolina | Sub | 32.2733° N | 80.5850° W
8661529 | Captain Alex's Marina, Parsonage Creek, Murrells Inlet, South Carolina | Sub | 33.5517° N | 79.0367° W
8725383 | Captiva Island (outside), Florida | Sub | 26.4783° N | 82.1833° W
8725417 | Captiva Island, Pine Island Sound, Florida | Sub | 26.5217° N | 82.1883° W
ACT8311_1 | Captiva Pass, Florida Current | Sub | 26.6093° N | 82.2223° W
8723491 | Card Sound, western side, Florida | Sub | 25.3450° N | 80.3317° W
8725325 | Carlos Point, Estero Bay, Florida | Sub | 26.4050° N | 81.8850° W
8530528 | Carlstadt, Garretts Reach, Hackensack River, New Jersey | Sub | 40.8067° N | 74.0600° W
9413375 | Carmel Cove, Carmel Bay, California | Sub | 36.5200° N | 121.9400° W
8661873 | Carr Creek, 1 mile above entrance, Great Pee Dee River, South Carolina | Sub | 33.4650° N | 79.1867° W
8728464 | Carrabelle, Carrabelle River, St. George Sound, Florida | Ref | 29.8500° N | 84.6650° W
8728464 | Carrabelle, Carrabelle River, St. George Sound, Florida (sub) | Sub | 29.8500° N | 84.6650° W
ACT6401_1 | Carrot Island (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.7022° N | 76.6175° W
9457293 | Carry Inlet, Shuyak Island, Alaska | Sub | 58.5867° N | 152.5130° W
PCT4416_1 | Carson Creek Entrance, 1.4 nmi. ESE of (Depth 15ft), Icy Bay, Alaska Current | Sub | 59.9833° N | 141.4700° W
PCT4426_1 | Carson Creek Entrance, 2.4 nmi. ESE of (Depth 50ft), Icy Bay, Alaska Current | Sub | 59.9867° N | 141.4367° W
PCT4421_1 | Carson Creek Entrance, 3.3 nmi. SE of (Depth 78ft), Icy Bay, Alaska Current | Sub | 59.9700° N | 141.4133° W
9465601 | Carter Bay, Kuskokwim Bay, Alaska | Ref | 59.3780° N | 162.0293° W
PCT5826_1 | Carter Bay, west of, Kuskokwim Bay, Alaska Current | Sub | 59.2833° N | 162.3667° W
8531095 | Carteret, Arthur Kill, New Jersey | Sub | 40.5867° N | 74.2100° W
8667679 | Carters Dock, Big Bay Creek, South Edisto River, South Carolina | Sub | 32.4933° N | 80.3267° W
8723583 | Carysfort Reef, Florida | Sub | 25.2217° N | 80.2117° W
9436381 | Cascade Head, Salmon River, Oregon | Ref | 45.0479° N | 124.0073° W
8663461 | Casino Creek, ICWW, South Carolina | Sub | 33.1083° N | 79.3933° W
8414672 | Castine, Penobscot Bay, Maine | Sub | 44.3867° N | 68.7967° W
9458907 | Castle Bay, Northwest Arm, Alaska | Ref | 56.2317° N | 158.3470° W
TEC2863 | Castle Hayne, Northeast River, Cape Fear River, North Carolina | Sub | 34.3500° N | 77.9333° W
8453201 | Castle Hill, Narragansett Bay, Rhode Island | Sub | 41.4633° N | 71.3617° W
ACT2101_1 | Castle Hill, west of, East Passage (Depth 15ft), Narragansett Bay, Rhode Island Current | Sub | 41.4567° N | 71.3783° W
ACT6676_1 | Castle Pinckney, 0.4 mile south of, Charleston Harbor, South Carolina Current | Sub | 32.7670° N | 79.9117° W
ACT6686_1 | Castle Pinckney, 0.6 mile southwest of, Charleston Harbor, South Carolina Current | Sub | 32.7663° N | 79.9195° W
8518989 | Castleton, Hudson River, New York | Sub | 42.5333° N | 73.7667° W
8745799 | Cat Island, Mississippi | Sub | 30.2317° N | 89.1167° W
8728619 | Cat Point, Apalachicola Bay, Florida | Ref | 29.7233° N | 84.8867° W
8728619 | Cat Point, Apalachicola Bay, Florida (sub) | Sub | 29.7233° N | 84.8867° W
9410092 | Catalina Harbor, Santa Catalina Island, California | Sub | 33.4317° N | 118.5030° W
9438772 | Cathcart Landing, Youngs River, Oregon | Ref | 46.1243° N | 123.8043° W
PCT1231_1 | Cathlamet Channel, SE of Nassa Point (Depth 19ft), Washington Current | Sub | 46.1562° N | 123.3150° W
ACT8456_1 | Cats Point (bridge west of), Tampa Bay, Florida Current | Sub | 27.7083° N | 82.7247° W
8514422 | Cedar Beach, Long Island, New York | Ref | 40.9650° N | 73.0433° W
8514422 | Cedar Beach, Long Island, New York (sub) | Sub | 40.9650° N | 73.0433° W
8537101 | Cedar Creek entrance, Nantuxent Cove, Delaware Bay, New Jersey | Sub | 39.2983° N | 75.2467° W
8533295 | Cedar Creek, Barnegat Bay, New Jersey | Sub | 39.8700° N | 74.1550° W
ACT7691_1 | Cedar Hammock, south of (Depth 12ft), Sapelo Sound, Georgia Current | Sub | 31.5450° N | 81.2467° W
8720189 | Cedar Heights, Broward River, Florida | Ref | 30.4367° N | 81.6417° W
8663381 | Cedar Island Point, South Santee River, South Carolina | Sub | 33.1200° N | 79.2700° W
8663261 | Cedar Island, North Santee Bay, South Carolina | Sub | 33.1400° N | 79.2450° W
8727520 | Cedar Key, Gulf Of Mexico, Florida | Ref | 29.1336° N | 83.0309° W
ACT4851_1 | Cedar Point, 1.1 miles ENE of, Chesapeake Bay, Maryland Current | Sub | 38.3045° N | 76.3517° W
ACT4846_1 | Cedar Point, 2.9 n.mi. ENE of (Depth 16ft), Chesapeake Bay, Maryland Current | Sub | 38.3108° N | 76.3133° W
ACT4846_2 | Cedar Point, 2.9 n.mi. ENE of (Depth 50ft), Chesapeake Bay, Maryland Current | Sub | 38.3108° N | 76.3133° W
8533941 | Cedar Run, Little Egg Harbor, New Jersey | Sub | 39.6533° N | 74.2567° W
8535001 | Cedar Swamp Creek, Tuckahoe River, Great Egg Harbor Bay, New Jersey | Sub | 39.2467° N | 74.7183° W
8448325 | Cedar Tree Neck, Martha's Vineyard, Massachusetts | Sub | 41.4350° N | 70.6967° W
8414168 | Center Harbor, Eggemoggin Reach, Maine | Sub | 44.2633° N | 68.5867° W
8573006 | Centreville Landing, Corsica River, Chester River, Maryland | Sub | 39.0533° N | 76.0750° W
8678466 | Ceylon, Satilla River, Georgia | Sub | 30.9633° N | 81.6550° W
8676012 | Champney Island, South Altamaha River, Georgia | Sub | 31.3317° N | 81.4600° W
9455249 | Chance Cove (Lagoon), Alaska | Sub | 59.4883° N | 150.3120° W
8571351 | Chance, Chesapeake Bay, Maryland | Sub | 38.1717° N | 75.9450° W
8760172 | Chandeleur Light, Louisiana | Sub | 30.0483° N | 88.8717° W
9458849 | Chankliut Island, Alaska | Sub | 56.1467° N | 158.1070° W
8723874 | Channel Five, east side, Hawk Channel, Florida | Sub | 24.8367° N | 80.7667° W
8723872 | Channel Five, west side, Hawk Channel, Florida | Sub | 24.8400° N | 80.7800° W
PCT3086_1 | Channel Island, north of, Alaska Current | Sub | 56.3752° N | 132.1697° W
8724507 | Channel Key, west side, Florida | Sub | 24.6033° N | 81.7250° W
8656554 | Channel Marker Lt. 59, North Carolina | Sub | 34.7033° N | 76.6200° W
8723868 | Channel Two, east, Lower Matecumbe Key, Fla. Bay, Florida | Sub | 24.8450° N | 80.7483° W
8723869 | Channel Two, west side, Hawk Channel, Florida | Sub | 24.8417° N | 80.7533° W
ACT6296_1 | Channel entrance, Ocracoke Inlet, Pamlico Sound, North Carolina Current | Sub | 35.0653° N | 76.0188° W
8729136 | Channel entrance, St. Andrew Bay, Florida | Sub | 30.1250° N | 85.7300° W
PCT1301_1 | Channel, 1.5 miles north of Westport, Grays Harbor, Washington Current | Sub | 46.9333° N | 124.1000° W
PCT1306_1 | Channel, 2.1 miles NNE of Westport, Grays Harbor, Washington Current | Sub | 46.9333° N | 124.0833° W
8447685 | Chapoquoit Point, West Falmouth Harbor, Buzzards Bay, Massachusetts | Ref | 41.6050° N | 70.6517° W
ACT6651_1 | Charleston Harbor (off Fort Sumter), South Carolina Current | Ref | 32.7560° N | 79.8703° W
ACT6636_1 | Charleston Hbr. ent. (between jetties), Charleston Harbor, South Carolina Current | Sub | 32.7333° N | 79.8333° W
8665530 | Charleston, Cooper River Entrance, South Carolina | Ref | 32.7808° N | 79.9236° W
9432780 | Charleston, Coos Bay, Oregon | Ref | 43.3450° N | 124.3220° W
8443838 | Charlestown, Charles River entrance, Boston Harbor, Massachusetts | Sub | 42.3717° N | 71.0550° W
8573968 | Charlestown, Northeast River, Chesapeake Bay, Maryland | Sub | 39.5733° N | 75.9700° W
9751639 | Charlotte Amalie, St. Thomas, Virgin Islands | Ref | 18.3358° N | 64.9200° W
8727246 | Chassahowitzka, Chassahowitzka River, Florida | Ref | 28.7150° N | 82.5767° W
8727246 | Chassahowitzka, Chassahowitzka River, Florida (sub) | Sub | 28.7150° N | 82.5767° W
8724891 | Chatham River entrance, Florida | Sub | 25.6900° N | 81.2850° W
8447435 | Chatham, Cape Cod, Massachusetts | Ref | 41.6885° N | 69.9511° W
8447435 | Chatham, Cape Cod, Massachusetts (sub) | Sub | 41.6885° N | 69.9511° W
8447505 | Chatham, Stage Harbor, Cape Cod, Massachusetts | Ref | 41.6667° N | 69.9667° W
8447505 | Chatham, Stage Harbor, Cape Cod, Massachusetts (sub) | Sub | 41.6667° N | 69.9667° W
8637472 | Cheatham Annex, York River, Virginia | Sub | 37.2917° N | 76.5867° W
8668301 | Chechessee Bluff, Chechessee River, South Carolina | Sub | 32.3733° N | 80.8367° W
8531223 | Cheesequake Creek, Garden State Parkway, New Jersey | Ref | 40.4533° N | 74.2733° W
8761487 | Chef Menteur, Chef Menteur Pass, Louisiana | Sub | 30.0650° N | 89.8000° W
8443725 | Chelsea St. Bridge, Chelsea River, Boston Harbor, Massachusetts | Ref | 42.3867° N | 71.0233° W
8443725 | Chelsea St. Bridge, Chelsea River, Boston Harbor, Massachusetts (sub) | Sub | 42.3867° N | 71.0233° W
TEC1645 | Chelsea, Arthur Kill, New Jersey | Sub | 40.6000° N | 74.2000° W
9454787 | Chenega Island, Dangerous Passage, Prince William Sound, Alaska | Sub | 60.3300° N | 148.1430° W
9454777 | Chenega Island, southwest end, Prince William Sound, Alaska | Sub | 60.2833° N | 148.1130° W
9462501 | Chernofski Harbor, Unalaska Island, Alaska | Sub | 53.3950° N | 167.5330° W
8660265 | Cherry Grove (inside), South Carolina | Sub | 33.8350° N | 78.6333° W
8571881 | Cherry Island, Beckwiths Creek, Little Choptank River, Maryland | Sub | 38.5617° N | 76.2083° W
9449424 | Cherry Point, Strait of Georgia, Washington | Ref | 48.8633° N | 122.7580° W
ACT4981_1 | Chesapeake Bay Bridge, main channel, Chesapeake Bay, Maryland Current | Sub | 38.9917° N | 76.3850° W
8638901 | Chesapeake Bay Bridge-Tunnel, Chesapeake Bay, Virginia | Ref | 37.0329° N | 76.0833° W
8638863 | Chesapeake Bay Bridge-Tunnel, Virginia | Ref | 36.9667° N | 76.1133° W
8576363 | Chesapeake Beach, Chesapeake Bay, Maryland | Sub | 38.7000° N | 76.5333° W
8573927 | Chesapeake City, Chesapeake and Delaware Canal, Maryland | Ref | 39.5267° N | 75.8100° W
8573927 | Chesapeake City, Chesapeake and Delaware Canal, Maryland (sub) | Sub | 39.5267° N | 75.8100° W
8633362 | Chesconessex Creek, Schooner Bay, Chesapeake Bay, Virginia | Sub | 37.7633° N | 75.7733° W
8720023 | Chester, Bells River, Florida | Ref | 30.6833° N | 81.5333° W
8720023 | Chester, Bells River, Florida (sub) | Sub | 30.6833° N | 81.5333° W
8638491 | Chester, James River, Virginia | Sub | 37.3833° N | 77.3783° W
8573343 | Chestertown, Chester River, Maryland | Sub | 39.2067° N | 76.0633° W
ACT6146_1 | Chestertown, Chester River, Maryland Current | Sub | 39.2072° N | 76.0612° W
9414863 | Chevron Oil Company Pier, Richmond, San Francisco Bay, California | Ref | 37.9230° N | 122.4096° W
9414863 | Chevron Oil Company Pier, Richmond, San Francisco Bay, California (sub) | Sub | 37.9230° N | 122.4096° W
9459085 | Chiachi Island (east side), Alaska | Sub | 55.8433° N | 159.1050° W
TWC2315 | Chichagof Harbor, Attu Island, Alaska | Sub | 52.9167° N | 173.2167° E
8737138 | Chickasaw Creek, Alabama | Ref | 30.7819° N | 88.0736° W
9458917 | Chignik, Anchorage Bay, Alaska | Sub | 56.2967° N | 158.4000° W
ACT6886_1 | Childsbury, S.A.L. RR. bridge, Cooper River, Charleston Harbor, South Carolina Current | Sub | 33.0938° N | 79.9425° W
9452421 | Chilkat Inlet, Lynn Canal, Alaska | Ref | 59.1700° N | 135.4000° W
9452421 | Chilkat Inlet, Lynn Canal, Alaska (sub) | Sub | 59.1700° N | 135.4000° W
8630308 | Chincoteague Channel (south end), Chincoteague Bay, Virginia | Ref | 37.9067° N | 75.4050° W
8630308 | Chincoteague Channel (south end), Chincoteague Bay, Virginia (sub) | Sub | 37.9067° N | 75.4050° W
8630194 | Chincoteague Island, Blake Cove, Virginia | Sub | 37.9517° N | 75.3550° W
8630229 | Chincoteague Island, Lewis Creek, Virginia | Sub | 37.9383° N | 75.3733° W
8630225 | Chincoteague Island, Oyster Bay, Virginia | Sub | 37.9417° N | 75.3467° W
8630249 | Chincoteague Island, USCG station, Virginia | Ref | 37.9317° N | 75.3833° W
9435992 | Chinook Bend, Siletz River, Oregon | Ref | 44.8800° N | 123.9636° W
PCT1171_1 | Chinook Point, WSW of (Depth 14ft), Washington Current | Sub | 46.2422° N | 123.9642° W
9440573 | Chinook, Baker Bay, Washington | Sub | 46.2717° N | 123.9480° W
9455735 | Chinulna Point, Cook Inlet, Alaska | Ref | 60.5033° N | 151.2830° W
9458293 | Chirikof Island, Alaska | Ref | 55.8083° N | 155.7400° W
ACT5991_1 | Chlora Point, 0.5 n.mi. SSW of (Depth 17ft), Choptank River, Maryland Current | Sub | 38.6283° N | 76.1517° W
ACT5991_2 | Chlora Point, 0.5 n.mi. SSW of (Depth 24ft), Choptank River, Maryland Current | Sub | 38.6283° N | 76.1517° W
8724919 | Chokoloskee, Florida | Sub | 25.8133° N | 81.3633° W
ACT7216_1 | Chowan Creek (Depth 15ft), Port Royal Sound, South Carolina Current | Sub | 32.3700° N | 80.6383° W
9458519 | Chowiet Island, Semidi Island, Alaska | Ref | 56.0517° N | 156.6980° W
9458519 | Chowiet Island, Semidi Island, Alaska (sub) | Sub | 56.0517° N | 156.6980° W
9751364 | Christiansted Harbor, St. Croix, Virgin Islands | Ref | 17.7500° N | 64.7050° W
8772132 | Christmas Bay, Texas | Sub | 29.0417° N | 95.1750° W
8723457 | Christmas Point, Elliott Key, Florida | Sub | 25.3917° N | 80.2300° W
TWC1169 | Chuckanut Bay, Bellingham Bay, Washington | Sub | 48.6667° N | 122.5000° W
8666029 | Church Creek bridge, Wadmalaw River, South Carolina | Sub | 32.7150° N | 80.0917° W
8665763 | Church Flats, Stono River, South Carolina | Sub | 32.7467° N | 80.1650° W
1840000 | Chuuk, Moen Island, E. Caroline Islands, FSM | Ref | 7.4467° N | 151.8470° E
TPT2659 | Chuuk, Moen Island, E. Caroline Islands, FSM (sub) | Sub | 7.4500° N | 151.8500° E
8572468 | Claiborne, Eastern Bay, Chesapeake Bay, Maryland | Sub | 38.8367° N | 76.2800° W
9445938 | Clam Bay, Rich Passage, Puget Sound, Washington | Sub | 47.5733° N | 122.5430° W
8662299 | Clambank Creek Dock, Goat Island, North Inlet, South Carolina | Ref | 33.3333° N | 79.1933° W
8720198 | Clapboard Creek, Pelotes Island, Florida | Ref | 30.4067° N | 81.5100° W
8638449 | Claremont, James River, Virginia | Sub | 37.2317° N | 76.9483° W
8667633 | Clarendon Plantation, South Carolina | Ref | 32.5025° N | 80.7841° W
8667633 | Clarendon Plantation, South Carolina (sub) | Sub | 32.5025° N | 80.7841° W
PCT5811_1 | Clarks Point, 1 mile west of, Alaska Current | Sub | 58.8333° N | 158.5833° W
8447712 | Clarks Point, New Bedford, Buzzards Bay, Massachusetts | Ref | 41.5933° N | 70.9000° W
8447712 | Clarks Point, New Bedford, Buzzards Bay, Massachusetts (sub) | Sub | 41.5933° N | 70.9000° W
9465261 | Clarks Point, Nushagak Bay, Alaska | Ref | 58.8483° N | 158.5520° W
9415846 | Clarksburg, Sacramento River, California | Sub | 38.4167° N | 121.5230° W
PCT1121_1 | Clatsop Spit, NNE of (Depth 15ft), Washington Current | Sub | 46.2462° N | 123.9942° W
PCT4411_1 | Claybluff Point Light, 2.3 nmi. SE of (Depth 206ft), Icy Bay, Alaska Current | Sub | 59.9467° N | 141.5200° W
PCT4406_1 | Claybluff Point Light, 3.5 nmi. south of (Depth 75ft), Icy Bay, Alaska Current | Sub | 59.9100° N | 141.5950° W
8770933 | Clear Lake, Galveston Bay, Texas | Ref | 29.5633° N | 95.0667° W
8770933 | Clear Lake, Galveston Bay, Texas (sub) | Sub | 29.5633° N | 95.0667° W
8726724 | Clearwater Beach, Gulf Of Mexico, Florida | Ref | 27.9783° N | 82.8317° W
8726724 | Clearwater Beach, Gulf Of Mexico, Florida (sub) | Sub | 27.9783° N | 82.8317° W
ACT8656_1 | Clearwater Pass, 0.2 mi. NE of Sand Key, Florida Current | Sub | 27.9567° N | 82.8233° W
8726706 | Clearwater, Florida | Sub | 27.9550° N | 82.8067° W
9451718 | Cleveland Passage, Whitney Island, Frederick Sound, Alaska | Sub | 57.2183° N | 133.5120° W
8417821 | Cliff Island, Luckse Sound, Casco Bay, Maine | Sub | 43.6950° N | 70.1100° W
PCT2696_1 | Cliff Point, 1 mile east from, Portland Canal, Alaska Current | Sub | 54.8000° N | 130.3167° W
8573125 | Cliffs Point, Chester River, Maryland | Sub | 39.1067° N | 76.1417° W
8573137 | Cliffs Wharf, Chester River, Maryland | Sub | 39.1100° N | 76.1383° W
8578931 | Clifton Beach, Smith Point, Potomac River, Maryland | Sub | 38.4133° N | 77.2667° W
PCT1206_1 | Clifton Channel (Depth 10ft), Washington Current | Sub | 46.2178° N | 123.4653° W
8463701 | Clinton Harbor, Connecticut | Ref | 41.2683° N | 72.5317° W
8664688 | Clouter Creek, north entrance, Cooper River, South Carolina | Sub | 32.9067° N | 79.9350° W
8664945 | Clouter Creek, south entrance, Cooper River, South Carolina | Sub | 32.8600° N | 79.9383° W
8668529 | Club Bridge Creek ent., Trenchards Inlet, South Carolina | Sub | 32.3350° N | 80.5417° W
8779748 | Coast Guard Station, South Padre Island, Texas | Ref | 26.0731° N | 97.1675° W
ACT6276_2 | Coast Guard Tower, southwest of (Depth 12ft), Oregon Inlet, North Carolina Current | Sub | 35.7617° N | 75.5317° W
ACT6276_1 | Coast Guard Tower, southwest of (Depth 6ft), Oregon Inlet, North Carolina Current | Sub | 35.7617° N | 75.5317° W
8736897 | Coast Guard sector, Mobile, Alabama | Ref | 30.6483° N | 88.0583° W
8533055 | Coates Point, Barnegat Bay, New Jersey | Sub | 39.9483° N | 74.1150° W
9418637 | Cockrobin Island Bridge, Eel River, San Francisco, California | Ref | 40.6372° N | 124.2822° W
8721649 | Cocoa Beach, Florida | Ref | 28.3683° N | 80.6000° W
8724098 | Cocoanut Key, Florida Bay, Florida | Sub | 24.7450° N | 81.2367° W
8762928 | Cocodrie, Terrebonne Bay, Louisiana | Ref | 29.2450° N | 90.6617° W
8725228 | Cocohatchee River, U.S. 41 bridge, Florida | Sub | 26.2817° N | 81.8017° W
8725319 | Coconut Point, Estero Bay, Florida | Ref | 26.4000° N | 81.8433° W
TEC3417 | Coffee Bluff, Forest River, Georgia | Sub | 31.9333° N | 81.1500° W
8410714 | Coffin Point, Coffin Neck, Maine | Ref | 44.8700° N | 67.1083° W
8410714 | Coffin Point, Coffin Neck, Maine (sub) | Sub | 44.8700° N | 67.1083° W
8444762 | Cohasset Harbor (White Head), Massachusetts | Sub | 42.2483° N | 70.7850° W
8571181 | Colburn Creek, Big Annemessex River, Chesapeake Bay, Maryland | Sub | 38.0483° N | 75.8033° W
9459949 | Cold Bay, Alaska | Ref | 55.2083° N | 162.6980° W
8516061 | Cold Spring Harbor, Oyster Bay, New York | Ref | 40.8733° N | 73.4700° W
8516061 | Cold Spring Harbor, Oyster Bay, New York (sub) | Sub | 40.8733° N | 73.4700° W
ACT3356_1 | College Point Reef, 0.25 n.mi. NW of (Depth 15ft), East River, New York Current | Sub | 40.8010° N | 73.8547° W
8517276 | College Pt, Ft. of 110th Street, Long Island, New York | Ref | 40.7833° N | 73.8567° W
8517276 | College Pt, Ft. of 110th Street, Long Island, New York (sub) | Sub | 40.7833° N | 73.8567° W
8668619 | Colleton River Entrance, South Carolina | Sub | 32.3217° N | 80.7917° W
9415176 | Collinsville, Sacramento River, California | Sub | 38.0733° N | 121.8480° W
8635150 | Colonial Beach, Potomac River, Virginia | Ref | 38.2517° N | 76.9600° W
8578465 | Colton Point, Potomac River, Maryland | Sub | 38.2233° N | 76.7483° W
9440574 | Columbia River entrance (N. Jetty), Washington | Sub | 46.2733° N | 124.0720° W
ACT7136_1 | Combahee River (Depth 15ft), South Carolina Current | Sub | 32.5500° N | 80.5633° W
ACT7131_1 | Combahee River (Depth 8ft), South Carolina Current | Sub | 32.5267° N | 80.5367° W
9454157 | Comfort Cove, Port Gravina, Prince William Sound, Alaska | Sub | 60.7100° N | 146.0850° W
8760742 | Comfort Island, Louisiana | Sub | 29.8233° N | 89.2700° W
ACT8036_2 | Commodore Point, terminal channel (Depth 17ft), St. Johns River, Florida Current | Sub | 30.3175° N | 81.6263° W
ACT8036_3 | Commodore Point, terminal channel (Depth 27ft), St. Johns River, Florida Current | Sub | 30.3175° N | 81.6263° W
ACT8036_1 | Commodore Point, terminal channel (Depth 7ft), St. Johns River, Florida Current | Sub | 30.3175° N | 81.6263° W
ACT2176_1 | Common Fence Point, west of (Depth 10ft), Narragansett Bay, Rhode Island Current | Sub | 41.6500° N | 71.2450° W
9452682 | Composite Island, Glacier Bay, Alaska | Sub | 58.8883° N | 136.5730° W
8453465 | Conanicut Point, Conanicut Island, Rhode Island | Sub | 41.5733° N | 71.3717° W
ACT2151_1 | Conanicut Point, ENE of (Depth 15ft), Narragansett Bay, Rhode Island Current | Sub | 41.5750° N | 71.3417° W
8722471 | Conch Bar, Jupiter Sound, Florida | Sub | 26.9883° N | 80.0933° W
8723906 | Conch Key, eastern end, Florida | Sub | 24.7917° N | 80.8833° W
8517741 | Coney Island, New York | Sub | 40.5700° N | 73.9833° W
8452944 | Conimicut Light, Narragansett Bay, Rhode Island | Ref | 41.7167° N | 71.3433° W
8530985 | Constable Hook, Kill Van Kull, New York | Sub | 40.6550° N | 74.0850° W
TWC2303 | Constantine Harbor, Amchitka Island, Rat Islands, Alaska | Sub | 51.4167° N | 179.2833° E
8724307 | Content Keys, Content Passage, Florida | Sub | 24.7900° N | 81.4833° W
8660275 | Conway, RR. bridge, Waccamaw River, South Carolina | Sub | 33.8350° N | 79.0417° W
8669277 | Cook Landing Cemetery, New River, South Carolina | Sub | 32.1950° N | 81.0000° W
ACT5981_1 | Cook Point, 1.4 n.mi. NNW of (Depth 15ft), Choptank River, Maryland Current | Sub | 38.6472° N | 76.3067° W
ACT5981_2 | Cook Point, 1.4 n.mi. NNW of (Depth 45ft), Choptank River, Maryland Current | Sub | 38.6472° N | 76.3067° W
9450533 | Coon Island, George Inlet, Revillagigedo Channel, Alaska | Sub | 55.4617° N | 131.5050° W
8724964 | Coon Key Pass, Gullivan Bay, Florida | Ref | 25.8967° N | 81.6367° W
8724964 | Coon Key Pass, Gullivan Bay, Florida (sub) | Sub | 25.8967° N | 81.6367° W
8723391 | Coon Point, Elliott Key, Biscayne Bay, Florida | Sub | 25.4800° N | 80.1883° W
8537779 | Coopers Creek bridge, Alloway Creek, New Jersey | Sub | 39.5133° N | 75.4467° W
PCT1061_1 | Coos Bay entrance, Oregon Current | Sub | 43.3550° N | 124.3412° W
9432845 | Coos Bay, Oregon | Sub | 43.3800° N | 124.2150° W
ACT7156_1 | Coosaw Island, South of, Morgan River (Depth 10ft), South Carolina Current | Sub | 32.4517° N | 80.5833° W
8774513 | Copano Bay State Fishing Pier, Texas | Ref | 28.1144° N | 97.0244° W
9450369 | Copper Harbor, Hetta Inlet, Alaska | Sub | 55.2100° N | 132.6250° W
PCT1056_1 | Coquille River entrance, Oregon Current | Sub | 43.1217° N | 124.4197° W
PCT3521_1 | Cora Point, 2 miles east of, Sumner Strait, Alaska Current | Sub | 55.9167° N | 134.0500° W
8656566 | Coral Bay, Atlantic Beach, North Carolina | Sub | 34.7000° N | 76.7683° W
9751373 | Coral Harbor, St. John, Virgin Islands | Ref | 18.3483° N | 64.7167° W
8723251 | Coral Shoal, Biscayne Channel, Florida | Sub | 25.6517° N | 80.1600° W
9454050 | Cordova, Orca Inlet, Prince William Sd, Alaska | Ref | 60.5583° N | 145.7550° W
8656084 | Core Creek Bridge, North Carolina | Sub | 34.8250° N | 76.6900° W
9414505 | Corkscrew Slough, San Francisco Bay, California | Sub | 37.5083° N | 122.2100° W
PCT3251_1 | Corlies Islands, Tlevak Strait, Alaska Current | Sub | 55.1333° N | 132.9667° W
8723532 | Cormorant Point, Key Largo, Card Sound, Florida | Sub | 25.2900° N | 80.3400° W
9447995 | Cornet Bay, Deception Pass, Washington | Sub | 48.4017° N | 122.6230° W
8575109 | Cornfield Creek, Magothy River, Chesapeake Bay, Maryland | Sub | 39.1000° N | 76.4450° W
8577940 | Cornfield Harbor, Potomac River, Maryland | Sub | 38.0600° N | 76.3617° W
8547333 | Cornwells Heights, Pennsylvania | Sub | 40.0683° N | 74.9383° W
PCT0091_1 | Coronado, off northeast end (Depth 14ft), San Diego Bay, California Current | Sub | 32.6980° N | 117.1638° W
PCT0091_2 | Coronado, off northeast end (Depth 38ft), San Diego Bay, California Current | Sub | 32.6980° N | 117.1638° W
PCT3351_1 | Coronados Islands, 2 miles west of, Alaska Current | Sub | 55.4333° N | 133.1667° W
9450829 | Coronation Island, Alaska | Sub | 55.9033° N | 134.1180° W
8775421 | Corpus Christi Naval Air Station, Texas | Ref | 27.7050° N | 97.2800° W
8775870 | Corpus Christi, Gulf Of Mexico, Texas | Ref | 27.5800° N | 97.2167° W
9414874 | Corte Madera Creek, San Francisco Bay, California | Sub | 37.9433° N | 122.5130° W
8726217 | Cortez, Sarasota Bay, Florida | Sub | 27.4667° N | 82.6867° W
ACT8396_1 | Cortez, north of bridge, Sarasota Bay, Florida Current | Sub | 27.4700° N | 82.6933° W
8469549 | Cos Cob Harbor, Connecticut | Sub | 41.0167° N | 73.5967° W
8665101 | Cosgrove Bridge, Ashley River, South Carolina | Sub | 32.8350° N | 79.9867° W
9441158 | Cosmopolis, Chehalis River, Grays Harbor, Washington | Sub | 46.9667° N | 123.7780° W
PCT3811_1 | Cosmos Point, 0.5 mile east of, Frederick Sound, Alaska Current | Sub | 56.6667° N | 132.6000° W
9451335 | Cosmos Point, Frederick Sound, Alaska | Sub | 56.6633° N | 132.6170° W
8764931 | Cote Blanche Island, West Cote Blanche Bay, Louisiana | Sub | 29.7350° N | 91.7133° W
ACT1756_1 | Cotuit Bay entrance (Bluff Point), Nantucket Sound, Massachusetts Current | Sub | 41.6100° N | 70.4300° W
8447675 | Cotuit Highlands, Nantucket Sound, Massachusetts | Sub | 41.6083° N | 70.4367° W
9447929 | Coupeville, Penn Cove, Whidbey Island, Washington | Sub | 48.2233° N | 122.6900° W
ACT4861_1 | Cove Point, 1.1 n.mi. east of (Depth 17ft), Chesapeake Bay, Maryland Current | Sub | 38.3813° N | 76.3603° W
ACT4861_2 | Cove Point, 1.1 n.mi. east of (Depth 40ft), Chesapeake Bay, Maryland Current | Sub | 38.3813° N | 76.3603° W
ACT4866_1 | Cove Point, 2.7 n.mi. east of (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 38.3800° N | 76.3253° W
ACT4866_2 | Cove Point, 2.7 n.mi. east of (Depth 40ft), Chesapeake Bay, Maryland Current | Sub | 38.3800° N | 76.3253° W
ACT4866_3 | Cove Point, 2.7 n.mi. east of (Depth 98ft), Chesapeake Bay, Maryland Current | Sub | 38.3800° N | 76.3253° W
ACT4871_1 | Cove Point, 3.9 n.mi. east of (Depth 11ft), Chesapeake Bay, Maryland Current | Sub | 38.3753° N | 76.2987° W
ACT4876_1 | Cove Point, 4.9 n.mi. NNE of (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 38.4672° N | 76.3767° W
ACT4876_2 | Cove Point, 4.9 n.mi. NNE of (Depth 40ft), Chesapeake Bay, Maryland Current | Sub | 38.4672° N | 76.3767° W
ACT4876_3 | Cove Point, 4.9 n.mi. NNE of (Depth 67ft), Chesapeake Bay, Maryland Current | Sub | 38.4672° N | 76.3767° W
9452346 | Cove Point, Berner's Bay, Lynn Canal, Alaska | Sub | 58.7517° N | 135.0280° W
8577188 | Cove Point, Chesapeake Bay, Maryland | Ref | 38.3917° N | 76.3983° W
8577188 | Cove Point, Chesapeake Bay, Maryland (sub) | Sub | 38.3917° N | 76.3983° W
8418009 | Cow Island, Casco Bay, Maine | Sub | 43.6900° N | 70.1900° W
8724527 | Cow Key Channel, Florida | Sub | 24.5700° N | 81.7500° W
8668173 | Cowen Creek, Rt. 21 bridge, Beaufort River, South Carolina | Sub | 32.3983° N | 80.6167° W
9414575 | Coyote Creek, Alviso Slough, San Francisco Bay, California | Ref | 37.4650° N | 122.0230° W
9414575 | Coyote Creek, Alviso Slough, San Francisco Bay, California (sub) | Sub | 37.4650° N | 122.0230° W
9414561 | Coyote Creek, Tributary no.1, San Francisco Bay, California | Sub | 37.4467° N | 121.9630° W
9414621 | Coyote Hills Slough entrance, San Francisco Bay, California | Sub | 37.5633° N | 122.1280° W
9414449 | Coyote Point Marina, San Francisco Bay, California | Sub | 37.5917° N | 122.3130° W
8662245 | Crab Haul Creek north inlet estuary, Oyster Landing, South Carolina | Ref | 33.3517° N | 79.1867° W
PCT3356_1 | Craig Cannery, Alaska Current | Sub | 55.4833° N | 133.1500° W
9450551 | Craig, Klawock Inlet, Bucareli Bay, Alaska | Ref | 55.4883° N | 133.1420° W
9450551 | Craig, Klawock Inlet, Bucareli Bay, Alaska (sub) | Sub | 55.4883° N | 133.1420° W
ACT5031_1 | Craighill Angle, right outside quarter, Chesapeake Bay, Maryland Current | Sub | 39.1283° N | 76.3878° W
ACT5001_1 | Craighill Channel entrance, Buoy '2C' (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 39.0403° N | 76.3778° W
ACT5001_2 | Craighill Channel entrance, Buoy '2C' (Depth 38ft), Chesapeake Bay, Maryland Current | Sub | 39.0403° N | 76.3778° W
ACT5026_1 | Craighill Channel, Belvidere Shoal (Depth 18ft), Chesapeake Bay, Maryland Current | Sub | 39.0947° N | 76.3930° W
ACT5021_1 | Craighill Channel, NE of Mountain Pt, Chesapeake Bay, Maryland Current | Sub | 39.0813° N | 76.3945° W
8534212 | Cramers Boatyard, Mullica River, New Jersey | Sub | 39.5483° N | 74.4617° W
8720004 | Crandall, St. Marys River, Florida | Ref | 30.7217° N | 81.6217° W
8723746 | Crane Keys, north side, Florida Bay, Florida | Sub | 25.0050° N | 80.6183° W
8638596 | Craney Island Light, Elizabeth River, Virginia | Sub | 36.8917° N | 76.3383° W
9455159 | Crater Bay, Harris Bay, Alaska | Ref | 59.7133° N | 149.7870° W
9455159 | Crater Bay, Harris Bay, Alaska (sub) | Sub | 59.7133° N | 149.7870° W
8724199 | Crawl Key, Big Spanish Channel, Florida | Sub | 24.7567° N | 81.3583° W
8674875 | Creighton Narrows entrance, Crescent River, Georgia | Sub | 31.4983° N | 81.3250° W
9443826 | Crescent Bay, Strait of Juan de Fuca, Washington | Sub | 48.1617° N | 123.7250° W
8720651 | Crescent Beach, Matanzas River, ICWW, Florida | Ref | 29.7683° N | 81.2583° W
9419750 | Crescent City, California | Ref | 41.7450° N | 124.1830° W
9447952 | Crescent Harbor, N. Whidbey Island, Washington | Sub | 48.2867° N | 122.6170° W
ACT7716_1 | Crescent River (Depth 11ft), Sapelo Sound, Georgia Current | Sub | 31.4867° N | 81.3067° W
8571091 | Crisfield, Little Annemessex River, Chesapeake Bay, Maryland | Ref | 37.9767° N | 75.8633° W
8571091 | Crisfield, Little Annemessex River, Chesapeake Bay, Maryland (sub) | Sub | 37.9767° N | 75.8633° W
8676808 | Crispen Island, Turtle River, Georgia | Ref | 31.2133° N | 81.5500° W
8676808 | Crispen Island, Turtle River, Georgia (sub) | Sub | 31.2133° N | 81.5500° W
9415143 | Crockett, Carquinez Strait, California | Ref | 38.0583° N | 122.2230° W
9415143 | Crockett, Carquinez Strait, California (sub) | Sub | 38.0583° N | 122.2230° W
8679242 | Crooked River, Cumberland Dividings, Georgia | Sub | 30.8433° N | 81.4867° W
9497778 | Cross Island (Dinkum Sands), Alaska | Ref | 70.4917° N | 147.9500° W
ACT1726_1 | Cross Rip Channel, Nantucket Sound, Massachusetts Current | Sub | 41.4483° N | 70.2917° W
8416928 | Cross River entrance, Sheepscot River, Maine | Sub | 43.9250° N | 69.6700° W
8444662 | Crow Point, Hingham Harbor entrance, Massachusetts | Sub | 42.2617° N | 70.8933° W
9410191 | Crown Point, Mission Bay, California | Sub | 32.7750° N | 117.2330° W
8573349 | Crumpton, Chester River, Maryland | Ref | 39.2450° N | 75.9250° W
8573349 | Crumpton, Chester River, Maryland (sub) | Sub | 39.2450° N | 75.9250° W
9450584 | Cruz Pass, San Fernando Island, Bucareli Bay, Alaska | Sub | 55.5417° N | 133.3150° W
ACT3341_1 | Cryders Point, 0.4 mile NNW of, East River, New York Current | Sub | 40.8003° N | 73.7987° W
8727343 | Crystal River, Kings Bay, Florida | Ref | 28.8983° N | 82.5983° W
8727343 | Crystal River, Kings Bay, Florida (sub) | Sub | 28.8983° N | 82.5983° W
8516221 | Cuba Island, Hempstead Bay, New York | Sub | 40.6200° N | 73.5233° W
8666166 | Cuckolds Creek, Combahee River, South Carolina | Sub | 32.7133° N | 80.6950° W
PCT3731_1 | Cucumber Reef, 0.2 mile northwest of, Keku Strait, Alaska Current | Sub | 56.7900° N | 133.7670° W
8724313 | Cudjoe Key, Cudjoe Bay, Florida | Sub | 24.6600° N | 81.4917° W
8724332 | Cudjoe Key, Pirates Cove, Florida | Sub | 24.6617° N | 81.5150° W
8724328 | Cudjoe Key, north end, Kemp Channel, Florida | Sub | 24.7000° N | 81.5050° W
9752235 | Culebra, Puerto Rico | Ref | 18.3009° N | 65.3025° W
TEC4741 | Culebrita, Isla, Puerto Rico | Sub | 18.3167° N | 65.2333° W
9454798 | Culross Bay, Wells Passage, Prince William Sound, Alaska | Sub | 60.7417° N | 148.1720° W
ACT7856_1 | Cumberland River, north entrance, St. Andrews Sound, Georgia Current | Sub | 30.9583° N | 81.4317° W
8678688 | Cumberland Wharf, Cumberland River, Georgia | Sub | 30.9300° N | 81.4467° W
8662216 | Cumberland, Sampit River, South Carolina | Sub | 33.3700° N | 79.4333° W
8417387 | Cundy Harbor, New Meadows River, Casco Bay, Maine | Sub | 43.7883° N | 69.8933° W
8720097 | Cuno, Lofton Creek, Nassau River, Florida | Sub | 30.5767° N | 81.5717° W
8417997 | Cushing Island, Casco Bay, Maine | Sub | 43.6450° N | 70.1983° W
9434068 | Cushman, Suislaw River, Oregon | Ref | 43.9850° N | 124.0450° W
9450296 | Custom House Cove, Mary Island, Alaska | Ref | 55.1000° N | 131.2170° W
PCT2866_1 | Customhouse Cove, 1 mile west of, Felice Strait, Alaska Current | Sub | 55.1000° N | 131.2667° W
ACT6701_1 | Customhouse Reach, Charleston Harbor, South Carolina Current | Sub | 32.7825° N | 79.9200° W
ACT6696_1 | Customhouse Reach, off Customhouse, Charleston Harbor, South Carolina Current | Sub | 32.7795° N | 79.9225° W
8720011 | Cut 1N front range, St. Marys River, Florida | Ref | 30.7083° N | 81.4650° W
8720012 | Cut 2N front range, St. Marys River, Florida | Ref | 30.7167° N | 81.3017° W
ACT8466_1 | Cut A & B, Channel Junction, Tampa Bay, Florida Current | Sub | 27.6388° N | 82.6255° W
8411060 | Cutler (Farris Wharf), Little River, Maine | Ref | 44.6570° N | 67.2047° W
8411060 | Cutler (Farris Wharf), Little River, Maine (sub) | Sub | 44.6570° N | 67.2047° W
8411250 | Cutler Naval Base, Machias Bay, Maine | Ref | 44.6417° N | 67.2967° W
8411250 | Cutler Naval Base, Machias Bay, Maine (sub) | Sub | 44.6417° N | 67.2967° W
8723289 | Cutler, Biscayne Bay, Florida | Ref | 25.6150° N | 80.3050° W
8448376 | Cuttyhunk, Massachusetts | Sub | 41.4250° N | 70.9167° W
9410988 | Cuyler Harbor, San Miguel Island, California | Sub | 34.0567° N | 120.3550° W
8765251 | Cypremort Point, Louisiana | Ref | 29.7134° N | 91.8800° W
TWC1579 | Cyrus Cove, Sea Otter Sound, Davidson Inlet, Alaska | Sub | 55.9167° N | 133.4000° W
8635027 | Dahlgren, Upper Machodoc Creek, Potomac River, Virginia | Ref | 38.3197° N | 77.0366° W
9466931 | Dall Point, Hooper Bay, Alaska | Ref | 61.5317° N | 166.1480° W
TEC3457 | Dallas Bluff, Julienton River, Georgia | Sub | 31.5833° N | 81.3167° W
8416796 | Damariscove Harbor, Damariscove Island, Maine | Sub | 43.7583° N | 69.6150° W
8720219 | Dame Point, St. Johns River, Florida | Ref | 30.3867° N | 81.5583° W
8720219 | Dame Point, St. Johns River, Florida (sub) | Sub | 30.3867° N | 81.5583° W
8445425 | Damons Point, North River, Massachusetts | Sub | 42.1600° N | 70.7333° W
PCT4101_1 | Danger Point Light, 3 miles west of, Chatham Strait, Alaska Current | Sub | 57.5167° N | 134.7000° W
ACT6796_1 | Daniel Island Bend, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.8483° N | 79.9292° W
ACT6781_1 | Daniel Island Reach, Buoy '48', Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.8272° N | 79.9288° W
ACT6791_1 | Daniel Island Reach, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.8328° N | 79.9300° W
8675779 | Darien, Darien River, Georgia | Sub | 31.3683° N | 81.4350° W
ACT7341_1 | Daufuskie Landing Light, south of (Depth 10ft), South Carolina Current | Sub | 32.1017° N | 80.8983° W
8669691 | Daufuskie Landing, Daufuskie Island, New River, South Carolina | Sub | 32.1033° N | 80.8950° W
8735181 | Dauphin Island Hydro, Alabama | Ref | 30.2513° N | 88.0795° W
8735180 | Dauphin Island, Mobile Bay, Alabama | Ref | 30.2500° N | 88.0750° W
8726657 | Davis Island, Hillsborough Bay, Florida | Sub | 27.9083° N | 82.4517° W
9450729 | Davis River entrance, Alaska | Sub | 55.7600° N | 130.1770° W
8652737 | Davis Slough, North Carolina | Sub | 35.7483° N | 75.5533° W
9415053 | Davis Slough, San Joaquin River, California | Sub | 38.0117° N | 121.6380° W
8656201 | Davis, Core Sound, North Carolina | Ref | 34.7968° N | 76.4555° W
8666799 | Dawho Bridge, Dawho River, North Edisto River, South Carolina | Sub | 32.6367° N | 80.3417° W
8666616 | Dawho River, South Edisto River, South Carolina | Sub | 32.6567° N | 80.3917° W
ACT7251_1 | Daws Island, SE of, Broad River (Depth 15ft), Port Royal Sound, South Carolina Current | Sub | 32.3017° N | 80.7250° W
ACT7261_1 | Daws Island, south of, Chechessee River (Depth 15ft), South Carolina Current | Sub | 32.2867° N | 80.7433° W
9455036 | Day Harbor, Alaska | Sub | 60.0100° N | 149.0620° W
8721020 | Daytona Beach (ocean), Florida | Ref | 29.2283° N | 81.0050° W
8721120 | Daytona Beach Shores, Sunglow Pier, Florida | Ref | 29.1467° N | 80.9633° W
8721120 | Daytona Beach Shores, Sunglow Pier, Florida (sub) | Sub | 29.1467° N | 80.9633° W
PCT1956_1 | Deception Pass (narrows), Washington Current | Ref | 48.4062° N | 122.6430° W
9448614 | Deception Pass St. Park, Bowman Bay, Fidalgo I., Washington | Ref | 48.4150° N | 122.6520° W
8639414 | Deep Creek Entrance, Elizabeth River, Virginia | Sub | 36.7550° N | 76.2933° W
8516225 | Deep Creek Meadow, Hempstead Bay, New York | Sub | 40.6033° N | 73.5250° W
8573211 | Deep Landing, Swan Creek, Chesapeake Bay, Maryland | Sub | 39.1450° N | 76.2600° W
8572204 | Deep Neck Point, Broad Creek, Chesapeake Bay, Maryland | Sub | 38.7317° N | 76.2350° W
ACT6141_1 | Deep Point, Chester River, Maryland Current | Sub | 39.1063° N | 76.1205° W
ACT6086_1 | Deepwater Point, Miles River, Eastern Bay, Maryland Current | Sub | 38.8055° N | 76.2092° W
8444012 | Deer Island (south end), Boston Harbor, Massachusetts | Sub | 42.3483° N | 70.9600° W
8743812 | Deer Island, Mississippi | Ref | 30.3833° N | 88.8667° W
8722832 | Deerfield Beach, Hillsboro River, Florida | Sub | 26.3133° N | 80.0817° W
9469751 | Deering, Kotzebue Sound, Alaska | Ref | 66.0972° N | 162.7405° W
8720214 | Degaussing structure, Mayport Naval Station, Florida | Ref | 30.3967° N | 81.3950° W
8551851 | Delaware City Branch Channel bridge, Delaware River, Delaware | Sub | 39.5700° N | 75.5900° W
8551762 | Delaware City, Delaware River, Delaware | Ref | 39.5817° N | 75.5883° W
8551762 | Delaware City, Delaware River, Delaware (sub) | Sub | 39.5817° N | 75.5883° W
8722746 | Delray Beach, ICWW, Florida | Sub | 26.4733° N | 80.0617° W
8515228 | Democrat Point, Fire Island Inlet, Long Island, New York | Sub | 40.6333° N | 73.2933° W
8536736 | Dennis Creek, 2.5 n.mi. above entrance, Delaware Bay, New Jersey | Sub | 39.1783° N | 74.8517° W
8536752 | Dennis Creek, Route 47 bridge, Delaware Bay, New Jersey | Sub | 39.1833° N | 74.8217° W
ACT1641_1 | Dennis Port, 2.2 miles south of, Nantucket Sound, Massachusetts Current | Sub | 41.6167° N | 70.1150° W
8447525 | Dennisport, Nantucket Sound, Massachusetts | Sub | 41.6583° N | 70.1150° W
9459281 | Dent Point, Stepovak Bay, Alaska | Sub | 55.7833° N | 159.8800° W
9435827 | Depoe Bay, Oregon | Ref | 44.8100° N | 124.0580° W
9435827 | Depoe Bay, Oregon (sub) | Sub | 44.8100° N | 124.0580° W
9446248 | Des Moines, East Passage, Puget Sound, Washington | Sub | 47.4000° N | 122.3280° W
TWC0965 | Destruction Island, Washington | Sub | 47.6667° N | 124.4833° W
ACT7021_1 | Deveaux Banks, off North Edisto River entrance (Depth 12ft), South Carolina Current | Sub | 32.5450° N | 80.1567° W
PCT3711_1 | Devils Elbow, Keku Strait, Alaska Current | Sub | 56.6362° N | 133.6895° W
9446671 | Devils Head, Drayton Passage, Puget Sound, Washington | Sub | 47.1667° N | 122.7630° W
8760417 | Devon Energy Facility, Louisiana | Ref | 29.2007° N | 89.0445° W
PCT3201_1 | Dewey Rocks, 2 miles west of, Cordova Bay, Alaska Current | Sub | 54.7500° N | 132.5333° W
8536449 | Dias Creek, Route 47 bridge, Delaware Bay, New Jersey | Sub | 39.0833° N | 74.8867° W
9437381 | Dick Point, Tillamook Bay, Oregon | Ref | 45.4817° N | 123.9020° W
PCT2711_1 | Dickens Point, Portland Canal, Alaska Current | Sub | 55.1500° N | 130.1500° W
8676722 | Dillard Creek, Turtle River, Georgia | Sub | 31.2250° N | 81.5717° W
8723205 | Dinner Key Marina, Biscayne Bay, Florida | Sub | 25.7267° N | 80.2367° W
8533982 | Dinner Point Creek, upper end, Little Egg Harbor, New Jersey | Sub | 39.6567° N | 74.2700° W
8724963 | Dismal Key, Pumpkin Bay, Florida | Ref | 25.8950° N | 81.5583° W
8724963 | Dismal Key, Pumpkin Bay, Florida (sub) | Sub | 25.8950° N | 81.5583° W
8668155 | Distant Island Creek, upper end, Cowen Creek, Beaufort River, South Carolina | Sub | 32.4017° N | 80.6533° W
8668282 | Distant Island, Cowen Creek, Beaufort River, South Carolina | Sub | 32.3783° N | 80.6333° W
PCT3296_1 | Diver Islands, Meares Passage, Alaska Current | Sub | 55.1833° N | 133.2833° W
9450399 | Divide Head, Cholmondeley Sound, Alaska | Sub | 55.2517° N | 132.3000° W
8536849 | Dividing Creek entrance, Delaware Bay, New Jersey | Sub | 39.2167° N | 75.1033° W
8661582 | Divine's Dock, Murrells Inlet, South Carolina | Sub | 33.5417° N | 79.0283° W
8727336 | Dixie Bay, Salt River, Crystal Bay, Florida | Ref | 28.8817° N | 82.6350° W
8727336 | Dixie Bay, Salt River, Crystal Bay, Florida (sub) | Sub | 28.8817° N | 82.6350° W
8636831 | Dixie, Piankatank River, Virginia | Sub | 37.5067° N | 76.4167° W
9452747 | Dixon Harbor, Alaska | Sub | 58.3833° N | 136.8670° W
ACT7761_1 | Doboy Island (North River) (Depth 12ft), Doboy Sound, Georgia Current | Sub | 31.4033° N | 81.3283° W
ACT7761_2 | Doboy Island (North River) (Depth 20ft), Doboy Sound, Georgia Current | Sub | 31.4033° N | 81.3283° W
8741041 | Dock E, Port of Pascagoula, Mississippi | Ref | 30.3478° N | 88.5058° W
8534739 | Dock Thorofare, Risley Channel, New Jersey | Sub | 39.3517° N | 74.5400° W
8723155 | Dodge Island, Fishermans Channel, Biscayne Bay, Florida | Sub | 25.7700° N | 80.1683° W
9446800 | Dofflemeyer Point, Boston Hbr., Budd Inlet, Puget Sound, Washington | Sub | 47.1417° N | 122.9030° W
8674623 | Dog Hammock, Sapelo River, Georgia | Sub | 31.5317° N | 81.2700° W
9751494 | Dog Island, St. Thomas, Virgin Islands | Ref | 18.2971° N | 64.8178° W
8728408 | Dog Island, east end, St. George Sound, Florida | Ref | 29.8100° N | 84.5850° W
8728465 | Dog Island, west end, St. George Sound, Florida | Sub | 29.7850° N | 84.6667° W
8735391 | Dog River Bridge, Alabama | Ref | 30.5652° N | 88.0880° W
9459758 | Dolgoi Harbor, Dolgoi Island, Alaska | Ref | 55.1217° N | 161.7920° W
9457481 | Dolphin Point, Raspberry Strait, Alaska | Sub | 58.1100° N | 153.1550° W
8725685 | Don Pedro Island State Park, cutoff (south), Florida | Ref | 26.8550° N | 82.3033° W
8722528 | Donald Ross Bridge, ICWW, Florida | Sub | 26.8817° N | 80.0700° W
9462971 | Dora Harbor, Unimak Island, Alaska | Sub | 54.7100° N | 163.2670° W
9751768 | Dorothea Bay, St. Thomas, Virgin Islands | Ref | 18.3712° N | 64.9635° W
9451376 | Dorothy Cove, Necker Bay, Baranof Island, Alaska | Sub | 56.7217° N | 135.0750° W
8533665 | Double Creek, Barnegat Bay, New Jersey | Sub | 39.7450° N | 74.2017° W
8669531 | Doughboy Island, New River, South Carolina | Sub | 32.1383° N | 80.9317° W
PCT3916_1 | Douglas, north of (Depth 15ft), Gastineau Channel, Stephens Passage, Alaska Current | Sub | 58.2830° N | 134.3937° W
PCT3916_2 | Douglas, north of (Depth 25ft), Gastineau Channel, Stephens Passage, Alaska Current | Sub | 58.2830° N | 134.3937° W
8678111 | Dover Bluff, Dover Creek, Georgia | Sub | 31.0167° N | 81.5283° W
8571944 | Dover Bridge, Choptank River, Maryland | Sub | 38.7567° N | 75.9983° W
ACT6021_1 | Dover Bridge, Choptank River, Maryland Current | Sub | 38.7567° N | 75.9987° W
8421897 | Dover Point, Piscataqua River, New Hampshire | Sub | 43.1217° N | 70.8333° W
8420411 | Dover, Cocheco River, Piscataqua River, New Hampshire | Ref | 43.1983° N | 70.8683° W
8420411 | Dover, Cocheco River, Piscataqua River, New Hampshire (sub) | Sub | 43.1983° N | 70.8683° W
9457393 | Dovolno Point, Kizhuyak Bay, Alaska | Ref | 57.7394° N | 152.8747° W
8417874 | Doyle Point, Casco Bay, Maine | Sub | 43.7517° N | 70.1400° W
9415020 | Drakes Bay, Point Reyes, California | Ref | 37.9961° N | 122.9767° W
9449679 | Drayton Harbor, Blaine, Strait of Georgia, Washington | Ref | 48.9917° N | 122.7650° W
9449679 | Drayton Harbor, Blaine, Strait of Georgia, Washington (sub) | Sub | 48.9917° N | 122.7650° W
8665002 | Drayton, Bee's Ferry, Ashley River, South Carolina | Sub | 32.8483° N | 80.0517° W
PCT2896_1 | Driest Point, Nichols Passage, Alaska Current | Sub | 55.1833° N | 131.6000° W
9434938 | Drift Creek, Alsea River, Oregon | Sub | 44.4133° N | 123.9900° W
9455741 | Drift River Terminal, Cook Inlet, Alaska | Sub | 60.5550° N | 152.1330° W
9462367 | Driftwood Bay, Umnak Island, Alaska | Sub | 52.9583° N | 168.7200° W
ACT6771_1 | Drum Island Reach, off Drum I., Buoy '45', Charleston Harbor, South Carolina Current | Sub | 32.8162° N | 79.9228° W
ACT6776_1 | Drum Island, 0.2 mile above, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.8197° N | 79.9292° W
ACT6756_1 | Drum Island, 0.4 mile SSE of, Charleston Harbor, South Carolina Current | Sub | 32.7945° N | 79.9208° W
ACT6761_1 | Drum Island, east of (bridge), Charleston Harbor, South Carolina Current | Sub | 32.8045° N | 79.9153° W
ACT5936_1 | Drum Point, 0.3 mile SSE of, Patuxent River, Maryland Current | Sub | 38.3155° N | 76.4192° W
ACT8016_2 | Drummond Point, channel south of (Depth 17ft), St. Johns River, Florida Current | Sub | 30.4092° N | 81.6028° W
ACT8016_3 | Drummond Point, channel south of (Depth 27ft), St. Johns River, Florida Current | Sub | 30.4092° N | 81.6028° W
ACT8016_1 | Drummond Point, channel south of (Depth 7ft), St. Johns River, Florida Current | Sub | 30.4092° N | 81.6028° W
9450998 | Dry Pass, El Capitan Passage, Alaska | Ref | 56.1633° N | 133.4130° W
TWC2077 | Dry Spruce Island, Kupreanof Strait, Alaska | Sub | 57.9500° N | 153.0333° W
9451301 | Dry Strait, Frederick Sound, Alaska | Sub | 56.6150° N | 132.5750° W
TPT2661 | Dublon Island, Chuuk, FSM | Sub | 7.3667° N | 151.8833° E
8665145 | Duck Island, Ashley River, South Carolina | Sub | 32.8300° N | 79.9667° W
8724474 | Duck Key Point, Duck Key, Waltz Key Basin, Florida | Sub | 24.6233° N | 81.6850° W
8723927 | Duck Key, Hawk Channel, Florida | Sub | 24.7650° N | 80.9133° W
8656483 | Duke Marine Lab, Beaufort, North Carolina | Ref | 34.7200° N | 76.6700° W
8656483 | Duke Marine Lab, Beaufort, North Carolina (sub) | Sub | 34.7200° N | 76.6700° W
9414509 | Dumbarton Highway Bridge, San Francisco Bay, California | Ref | 37.5067° N | 122.1150° W
9414509 | Dumbarton Highway Bridge, San Francisco Bay, California (sub) | Sub | 37.5067° N | 122.1150° W
8723044 | Dumfoundling Bay, Florida | Sub | 25.9417° N | 80.1250° W
9450286 | Dunbar Inlet GPS Tide Buoy, Alaska | Ref | 55.0879° N | 132.8158° W
8726761 | Dunedin, St. Joseph Sound, Florida | Sub | 28.0133° N | 82.7933° W
8679758 | Dungeness, Seacamp Dock, Georgia | Ref | 30.7633° N | 81.4717° W
8679758 | Dungeness, Seacamp Dock, Georgia (sub) | Sub | 30.7633° N | 81.4717° W
9444471 | Dungeness, Strait of Juan de Fuca, Washington | Sub | 48.1667° N | 123.1170° W
8660148 | Dunn Sound, Little River Inlet, South Carolina | Sub | 33.8583° N | 78.5700° W
8660147 | Dunn Sound, north end, South Carolina | Sub | 33.8600° N | 78.5800° W
8660195 | Dunn Sound, west end, South Carolina | Sub | 33.8517° N | 78.5883° W
9446828 | Dupont Wharf, Nisqually Reach, Puget Sound, Washington | Sub | 47.1183° N | 122.6650° W
8663757 | Dupont, Dean Hall, Cooper River, South Carolina | Sub | 33.0583° N | 79.9367° W
9462611 | Dutch Harbor, Amaknak Island, Unalaska Island, Alaska | Sub | 53.8917° N | 166.5370° W
ACT2211_1 | Dutch Island and Beaver Head, between, Narragansett Bay, Rhode Island Current | Sub | 41.4967° N | 71.4033° W
ACT7506_1 | Dutch Island, SE of, Skidaway River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 31.9917° N | 81.0200° W
ACT2216_1 | Dutch Island, west of (Depth 7ft), Narragansett Bay, Rhode Island Current | Sub | 41.5050° N | 71.4100° W
9447029 | Duwamish Waterway, Eighth Ave. South, Puget Sound, Washington | Sub | 47.5350° N | 122.3220° W
8446166 | Duxbury, Duxbury Harbor, Cape Cod Bay, Massachusetts | Ref | 42.0383° N | 70.6700° W
8446166 | Duxbury, Duxbury Harbor, Cape Cod Bay, Massachusetts (sub) | Sub | 42.0383° N | 70.6700° W
ACT2156_1 | Dyer Island, west of (Depth 7ft), Narragansett Bay, Rhode Island Current | Sub | 41.5867° N | 71.3083° W
ACT2146_1 | Dyer Island-Carrs Point (between), Narragansett Bay, Rhode Island Current | Sub | 41.5750° N | 71.2967° W
TWC2193 | Eagle Bay, Unalaska Island, Alaska | Sub | 53.4833° N | 166.9333° W
8674801 | Eagle Creek, Mud River, Georgia | Sub | 31.5100° N | 81.2783° W
9445882 | Eagle Harbor, Bainbridge Island, Puget Sound, Washington | Sub | 47.6200° N | 122.5150° W
PCT3706_1 | Eagle Island, 0.5 mile southeast of, Keku Strait, Alaska Current | Sub | 56.6073° N | 133.6822° W
8673875 | Eagle Neck, South Newport River, Georgia | Sub | 31.6500° N | 81.3050° W
8771013 | Eagle Point, Galveston Bay, Texas | Ref | 29.4800° N | 94.9183° W
8771013 | Eagle Point, Galveston Bay, Texas (sub) | Sub | 29.4800° N | 94.9183° W
ACT3476_1 | East 107th Street (Depth 15ft), Harlem River, New York Current | Sub | 40.7900° N | 73.9350° W
8518695 | East 41st Street, New York City, East River, New York | Sub | 40.7467° N | 73.9683° W
8723465 | East Arsenicker, Card Sound, Florida | Ref | 25.3733° N | 80.2900° W
8724094 | East Bahia Honda Key, south end, Florida Bay, Florida | Sub | 24.7750° N | 81.2267° W
8762372 | East Bank 1, Norco, Bayou LaBranche, Louisiana | Ref | 30.0503° N | 90.3680° W
8729702 | East Bay, Pensacola Bay, Florida | Ref | 30.4500° N | 86.9183° W
8729702 | East Bay, Pensacola Bay, Florida (sub) | Sub | 30.4500° N | 86.9183° W
8416721 | East Boothbay, Damariscotta River, Maine | Sub | 43.8650° N | 69.5833° W
ACT6891_1 | East Branch, 0.2 mile above entrance, Cooper River, South Carolina Current | Sub | 33.0683° N | 79.9200° W
PCT4176_1 | East Channel (narrows), Krestof Sound, Alaska Current | Sub | 57.1667° N | 135.5500° W
ACT1791_1 | East Chop, 1 mile north of, Nantucket Sound, Massachusetts Current | Sub | 41.4850° N | 70.5583° W
ACT1786_1 | East Chop-Squash Meadow, between, Nantucket Sound, Massachusetts Current | Sub | 41.4650° N | 70.5367° W
9462161 | East Cove, Yunaska Island, Alaska | Sub | 52.6533° N | 170.5630° W
8536823 | East Creek, Route 47 bridge, Delaware Bay, New Jersey | Sub | 39.2083° N | 74.9017° W
PCT2646_1 | East Devil Rock, 1 mile north of, Dixon Entrance, Alaska Current | Sub | 54.7000° N | 131.0833° W
TWC1989 | East Foreland, Cook Inlet, Alaska | Sub | 60.7167° N | 151.4167° W
8735523 | East Fowl River Bridge, Alabama | Ref | 30.4436° N | 88.1139° W
8454578 | East Greenwich, Narragansett Bay, Rhode Island | Ref | 41.6650° N | 71.4450° W
1619222 | East Island, French Frigate Shoals, Hawaii | Sub | 23.7833° N | 166.2080° W
8762888 | East Isle Dernière, Lake Pelto, Louisiana | Ref | 29.0717° N | 90.6400° W
8723752 | East Key, southern end, Florida Bay, Florida | Sub | 24.9967° N | 80.6100° W
8729511 | East Pass (Destin), Choctawhatchee Bay, Florida | Sub | 30.3950° N | 86.5133° W
8536780 | East Point, Maurice River Cove, Delaware Bay, New Jersey | Sub | 39.2000° N | 75.0200° W
PCT3121_1 | East Point, east of, Zimovia Strait, Alaska Current | Sub | 56.3833° N | 132.4000° W
8530403 | East Rutherford, Passaic River, New Jersey | Sub | 40.8467° N | 74.1200° W
8762223 | East Timbalier Island, Timbalier Bay, Louisiana | Ref | 29.0767° N | 90.2850° W
9466012 | Eastern Nunivak Island, Alaska | Ref | 60.0429° N | 165.6806° W
8572296 | Easton Point, Tred Avon River, Maryland | Sub | 38.7683° N | 76.0950° W
8410140 | Eastport, Passamaquoddy Bay, Maine | Ref | 44.9033° N | 66.9850° W
PCT3051_1 | Eaton Point, Ernest Sound, Alaska Current | Sub | 55.9528° N | 132.0900° W
8515786 | Eatons Neck Point, Long Island, New York | Ref | 40.9533° N | 73.4000° W
8515786 | Eatons Neck Point, Long Island, New York (sub) | Sub | 40.9533° N | 73.4000° W
TPT2705 | Ebon (Boston) Atoll, Marshall Islands | Sub | 4.6000° N | 168.6833° E
9449712 | Echo Bay, Sucia Islands, Strait of Georgia, Washington | Sub | 48.7567° N | 122.8970° W
8667972 | Edding Point, Edding Creek, Morgan River, South Carolina | Sub | 32.4467° N | 80.5333° W
8722312 | Eden, Nettles Island, Indian River, Florida | Sub | 27.2867° N | 80.2267° W
8448558 | Edgartown, Martha's Vineyard, Massachusetts | Ref | 41.3883° N | 70.5117° W
8448558 | Edgartown, Martha's Vineyard, Massachusetts (sub) | Sub | 41.3883° N | 70.5117° W
8549424 | Edgely, Pennsylvania | Sub | 40.1283° N | 74.8233° W
8550438 | Edgemoor, Delaware River, Delaware | Sub | 39.7500° N | 75.4933° W
9415415 | Edgerley Island, Napa River, California | Sub | 38.1917° N | 122.3120° W
8530505 | Edgewater, Hudson River, New Jersey | Sub | 40.8133° N | 73.9783° W
8575579 | Edgewater, South River, Chesapeake Bay, Maryland | Sub | 38.9500° N | 76.5500° W
8667630 | Edisto Beach, Edisto Island, South Carolina | Sub | 32.5017° N | 80.2967° W
8667676 | Edisto Marina, Big Bay Creek entrance, South Edisto River, South Carolina | Sub | 32.4933° N | 80.3400° W
9444122 | Ediz Hook, Port Angeles, Strait of Juan de Fuca, Washington | Sub | 48.1400° N | 123.4130° W
9447427 | Edmonds, Puget Sound, Washington | Sub | 47.8133° N | 122.3830° W
9450859 | Edna Bay, Davidson Inlet, Alaska | Sub | 55.9500° N | 133.6620° W
8720145 | Edwards Creek, Nassau River, Florida | Ref | 30.5017° N | 81.5417° W
8720145 | Edwards Creek, Nassau River, Florida (sub) | Sub | 30.5017° N | 81.5417° W
8449062 | Eel Point, Nantucket Island, Massachusetts | Sub | 41.2917° N | 70.2083° W
ACT1691_1 | Eel Pt., Nantucket I. 2.5 miles NE of, Nantucket Sound, Massachusetts Current | Sub | 41.3217° N | 70.1700° W
9464881 | Egegik River entrance, Alaska | Sub | 58.2383° N | 157.5000° W
9464874 | Egegik, Egegik River, Alaska | Sub | 58.2167° N | 157.3750° W
ACT7111_1 | Egg Bank, St. Helena Sound (Depth 10ft), South Carolina Current | Sub | 32.4350° N | 80.4433° W
TEC3413 | Egg Islands, Georgia | Sub | 31.8333° N | 81.0833° W
ACT8406_1 | Egmont Channel (3 mi. W of Egmont Key Lt.), Tampa Bay, Florida Current | Sub | 27.6083° N | 82.8183° W
ACT8401_1 | Egmont Channel, marker '10' (Depth 15ft), Tampa Bay, Florida Current | Sub | 27.6005° N | 82.8677° W
8726347 | Egmont Key, Egmont Channel, Tampa Bay, Florida | Ref | 27.6017° N | 82.7600° W
8726347 | Egmont Key, Egmont Channel, Tampa Bay, Florida (sub) | Sub | 27.6017° N | 82.7600° W
9450851 | El Capitan Island, Davidson Inlet, Alaska | Sub | 55.9367° N | 133.3250° W
9450997 | El Capitan Passage, Alaska | Ref | 56.1633° N | 133.3300° W
9450937 | El Capitan Passage, Alaska (sub) | Sub | 56.0733° N | 133.3130° W
8725769 | El Jobean, Myakka River, Florida | Sub | 26.9617° N | 82.2100° W
9410777 | El Segundo, Santa Monica Bay, California | Sub | 33.9083° N | 118.4330° W
ACT7376_1 | Elba Island Cut, NE of, Savannah River (Depth 10ft), South Carolina Current | Sub | 32.0733° N | 80.9650° W
ACT7381_1 | Elba Island, NE of, Savannah River (Depth 10ft), Savannah River, Georgia Current | Sub | 32.0900° N | 80.9933° W
ACT7386_1 | Elba Island, west of, Savannah River (Depth 10ft), Savannah River, Georgia Current | Sub | 32.0950° N | 81.0200° W
9450158 | Elbow Bay, Alaska | Sub | 54.9000° N | 132.6530° W
9452579 | Elbow Passage, Klag Bay, Chichagof Island, Alaska | Sub | 57.6133° N | 136.0870° W
8728786 | Eleven Mile, St. Vincent Sound, Florida | Ref | 29.7067° N | 85.1533° W
9452634 | Elfin Cove, Port Althorp, Cross Sound, Alaska | Ref | 58.1947° N | 136.3469° W
9452634 | Elfin Cove, Port Althorp, Cross Sound, Alaska (sub) | Sub | 58.1947° N | 136.3469° W
9451706 | Eliza Harbor, Admiralty Island, Frederick Sound, Alaska | Sub | 57.1883° N | 134.2870° W
TWC1669 | Eliza Harbor, Liesnoi Island, Frederick Sound, Alaska | Sub | 57.1667° N | 134.2833° W
9418757 | Elk River Railroad Bridge, Humboldt Bay, California | Sub | 40.7567° N | 124.1930° W
9413631 | Elkhorn Slough at Elkhorn, Monterey Bay, California | Ref | 36.8183° N | 121.7470° W
9413663 | Elkhorn Slough railroad bridge, Monterey Bay, California | Ref | 36.8567° N | 121.7550° W
9413623 | Elkhorn Slough, Highway 1 Bridge, Monterey Bay, California | Sub | 36.8100° N | 121.7850° W
9413626 | Elkhorn Yacht Club, Monterey Bay, California | Sub | 36.8133° N | 121.7870° W
8665641 | Elliott Cut entrance, Stono River, South Carolina | Sub | 32.7633° N | 80.0017° W
ACT6996_1 | Elliott Cut, west end, Stono River, South Carolina Current | Sub | 32.7667° N | 80.0000° W
8723409 | Elliott Key Harbor, Elliott Key, Biscayne Bay, Florida | Ref | 25.4533° N | 80.1967° W
8413801 | Ellsworth, Union River, Blue Hill Bay, Maine | Ref | 44.5350° N | 68.4217° W
8413801 | Ellsworth, Union River, Blue Hill Bay, Maine (sub) | Sub | 44.5350° N | 68.4217° W
8761212 | Empire Jetty, Louisiana | Sub | 29.2500° N | 89.6083° W
9432864 | Empire, Coos Bay, Oregon | Sub | 43.3917° N | 124.2800° W
8725747 | Englewood, Lemon Bay, Florida | Sub | 26.9333° N | 82.3533° W
9462641 | English Bay, Unalaska Island, Alaska | Sub | 53.9250° N | 166.2570° W
TPT2689 | Eniirikku Island, Bikini Atoll, Marshall Islands | Sub | 11.5000° N | 165.3333° E
TEC4749 | Ensenada Honda, Culebra Island, Puerto Rico | Sub | 18.3000° N | 65.2833° W
8661067 | Enterprise Landing, Waccamaw River, South Carolina | Sub | 33.6667° N | 79.0633° W
ACT7731_1 | Entrance (Depth 14ft), Doboy Sound, Georgia Current | Sub | 31.3417° N | 81.2633° W
ACT7681_1 | Entrance (Depth 19ft), Sapelo Sound, Georgia Current | Sub | 31.5400° N | 81.1800° W
ACT7731_2 | Entrance (Depth 22ft), Doboy Sound, Georgia Current | Sub | 31.3417° N | 81.2633° W
ACT7681_2 | Entrance (Depth 29ft), Sapelo Sound, Georgia Current | Sub | 31.5400° N | 81.1800° W
9451438 | Entrance Island, Keku Strait, Alaska | Ref | 56.8117° N | 133.7870° W
9451438 | Entrance Island, Keku Strait, Alaska (sub) | Sub | 56.8117° N | 133.7870° W
PCT5746_1 | Entrance Point, 3 miles west of, Port Moller, Alaska Current | Sub | 56.0000° N | 160.6500° W
PCT5751_1 | Entrance Point, Port Moller, Alaska Current | Sub | 55.9833° N | 160.5833° W
PCT1276_1 | Entrance, 0.2 mile south of north jetty, Grays Harbor, Washington Current | Sub | 46.9263° N | 124.1613° W
PCT1286_1 | Entrance, 0.6 mile WNW of Westport, Grays Harbor, Washington Current | Sub | 46.9147° N | 124.1250° W
PCT1296_1 | Entrance, 1.1 miles NW of Westport, Grays Harbor, Washington Current | Sub | 46.9167° N | 124.1333° W
PCT1281_1 | Entrance, Point Chehalis Range, Grays Harbor, Washington Current | Sub | 46.9083° N | 124.1555° W
ACT7846_1 | Entrance, St. Andrews Sound, Georgia Current | Sub | 30.9867° N | 81.4050° W
ACT7801_1 | Entrance, north of channel (Depth 13ft), St. Simons Sound, Georgia Current | Sub | 31.1335° N | 81.4040° W
ACT7446_1 | Entrance, off Beach Hammock, Wassaw Sound, Georgia Current | Sub | 31.9417° N | 80.9317° W
ACT7466_1 | Entrance, off Wassaw Island, Wassaw Sound, Georgia Current | Sub | 31.9167° N | 80.9467° W
ACT7806_1 | Entrance, south of channel (Depth 11ft), St. Simons Sound, Georgia Current | Sub | 31.1267° N | 81.4033° W
ACT7806_2 | Entrance, south of channel (Depth 29ft), St. Simons Sound, Georgia Current | Sub | 31.1267° N | 81.4033° W
TPT2717 | Erikub Atoll, Marshall Islands | Sub | 9.2000° N | 169.9167° E
9454735 | Eshamy Bay, Knight Island Passage, Prince William Sound, Alaska | Sub | 60.4483° N | 147.9780° W
9454757 | Eshamy Lagoon, Prince William Sound, Alaska | Sub | 60.4617° N | 148.0450° W
9752695 | Esperanza, Vieques Island, Puerto Rico | Ref | 18.0939° N | 65.4714° W
8462925 | Essex, Connecticut River, Connecticut | Sub | 41.3483° N | 72.3850° W
8441771 | Essex, Essex River, Massachusetts | Ref | 42.6317° N | 70.7767° W
8441771 | Essex, Essex River, Massachusetts (sub) | Sub | 42.6317° N | 70.7767° W
8725351 | Estero Island, Estero Bay, Florida | Ref | 26.4383° N | 81.9183° W
8725346 | Estero River, Estero Bay, Florida | Sub | 26.4300° N | 81.8567° W
9465249 | Estus Point, Hagemeister Strait, Alaska | Ref | 58.8083° N | 161.1000° W
TWC2321 | Etienne Bay, Attu Island, Alaska | Sub | 52.9167° N | 172.6167° E
PCT5806_1 | Etolin Point, 8.5 miles west of, Alaska Current | Sub | 58.6333° N | 158.5833° W
8764311 | Eugene Island, Atchafalaya Bay, Louisiana | Ref | 29.3717° N | 91.3850° W
8764314 | Eugene Island, north of, Louisiana | Ref | 29.3675° N | 91.3839° W
TEC3327 | Euhaw Creek, 2.5 mi. above entrance, Broad River, South Carolina | Sub | 32.4350° N | 80.8517° W
9418802 | Eureka Slough Bridge, Humboldt Bay, California | Sub | 40.8067° N | 124.1420° W
9418801 | Eureka, Humboldt Bay, California | Sub | 40.8067° N | 124.1670° W
PCT4321_1 | Eva Islands, Peril Strait, Alaska Current | Sub | 57.4500° N | 134.9333° W
9447659 | Everett, Washington | Ref | 47.9800° N | 122.2230° W
8724948 | Everglades City, Barron River, Florida | Sub | 25.8583° N | 81.3867° W
8571117 | Ewell, Smith Island, Chesapeake Bay, Maryland | Ref | 37.9950° N | 76.0317° W
8571117 | Ewell, Smith Island, Chesapeake Bay, Maryland (sub) | Sub | 37.9950° N | 76.0317° W
9452437 | Excursion Inlet Entrance, Icy Strait, Alaska | Sub | 58.4167° N | 135.4470° W
9452447 | Excursion Inlet, Icy Strait, Alaska | Sub | 58.4967° N | 135.4880° W
9461656 | Explorer Bay, Atka Island, Alaska | Sub | 52.0733° N | 174.5680° W
TWC1869 | Eyak River entrance, Alaska | Sub | 60.4667° N | 145.6667° W
8651370 | FRF Pier, Duck, North Carolina | Ref | 36.1833° N | 75.7467° W
TWC1787 | Fairway Island, Alaska | Sub | 57.4500° N | 134.8833° W
PCT4326_1 | Fairway Island, Peril Strait, Alaska Current | Sub | 57.4500° N | 134.8833° W
ACT8951_1 | Fajardo Harbor (channel), Puerto Rico Current | Sub | 18.3333° N | 65.6167° W
9753216 | Fajardo, Puerto Rico | Ref | 18.3352° N | 65.6311° W
TWC1789 | Falcon Arm, Slocum Arm, Chichagof Island, Alaska | Sub | 57.5500° N | 135.9333° W
8447386 | Fall River, Narragansett Bay, Massachusetts | Ref | 41.7043° N | 71.1641° W
8447386 | Fall River, Narragansett Bay, Massachusetts (sub) | Sub | 41.7043° N | 71.1641° W
8418015 | Falmouth Foreside, Casco Bay, Maine | Sub | 43.7317° N | 70.2050° W
8447865 | Falmouth Heights, Nantucket Sound, Massachusetts | Sub | 41.5450° N | 70.5933° W
9452328 | False Bay, Chatham Strait, Alaska | Ref | 57.9667° N | 134.9350° W
PCT4311_1 | False Linderberg Head, 1 mile south of, Peril Strait, Alaska Current | Sub | 57.4500° N | 135.0833° W
9462955 | False Pass, Isanotski Strait, Unimak Island, Alaska | Ref | 54.8583° N | 163.4070° W
9415145 | False River, San Joaquin River, California | Sub | 38.0550° N | 121.6570° W
8729017 | Farmdale, East Bay, St. Andrew Bay, Florida | Sub | 30.0167° N | 85.4700° W
8723949 | Fat Deer Key, Florida Bay, Florida | Sub | 24.7333° N | 81.0167° W
TWC1739 | Favorite Bay, Kootznahoo Inlet, Alaska | Sub | 57.4833° N | 134.5500° W
8658715 | Federal Point, Cape Fear River, North Carolina | Sub | 33.9617° N | 77.9400° W
9461519 | Fenimore Pass, Aleutian Islands, Alaska | Sub | 51.9600° N | 175.5880° W
ACT7066_1 | Fenwick Island Cut, South Edisto River (Depth 15ft), South Carolina Current | Sub | 32.5350° N | 80.4133° W
8667309 | Fenwick Island, South Edisto River, South Carolina | Sub | 32.5600° N | 80.4183° W
8720030 | Fernandina Beach, Amelia River, Florida | Ref | 30.6714° N | 81.4658° W
TWC1189 | Ferndale, Strait of Georgia, Washington | Sub | 48.8333° N | 122.7167° W
8571979 | Ferry Cove, Tilghman Island, Chesapeake Bay, Maryland | Sub | 38.7650° N | 76.3283° W
8638442 | Ferry Point (bridge), Chickahominy River, Virginia | Sub | 37.2633° N | 76.8767° W
8518902 | Ferry Slip, Dyckman Street, Hudson River, New York | Ref | 40.8683° N | 73.9333° W
8669815 | Fields Cut, Wright River, South Carolina | Sub | 32.0867° N | 80.9333° W
9418723 | Fields Landing, Humboldt Bay, California | Ref | 40.7233° N | 124.2220° W
8667259 | Fields Point, Combahee River, South Carolina | Sub | 32.5683° N | 80.5533° W
8539487 | Fieldsboro, Delaware River, New Jersey | Ref | 40.1367° N | 74.7367° W
8539487 | Fieldsboro, Delaware River, New Jersey (sub) | Sub | 40.1367° N | 74.7367° W
ACT7391_1 | Fig Island, north of, Back River, Savannah River, Georgia Current | Sub | 32.0850° N | 81.0500° W
ACT6816_1 | Filbin Creek Reach, 0.2 mile east of, Cooper River, South Carolina Current | Sub | 32.8880° N | 79.9605° W
ACT6821_1 | Filbin Creek Reach, Buoy '58', Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.8963° N | 79.9612° W
ACT6811_1 | Filbin Creek Reach, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.8887° N | 79.9653° W
9461945 | Finch Cove, Seguam Island, Aleutian Islands, Alaska | Sub | 52.3917° N | 172.4050° W
8515186 | Fire Island Coast Guard Station, Great South Bay, New York | Ref | 40.6267° N | 73.2600° W
8515014 | Fire Island Light, Great South Bay, New York | Sub | 40.6350° N | 73.2200° W
9455912 | Fire Island, Cook Inlet, Alaska | Ref | 61.1733° N | 150.2130° W
8530586 | Fish Creek, Berrys Creek, Hackensack River, New Jersey | Sub | 40.7933° N | 74.0917° W
8632085 | Fishermans Island, Chesapeake Bay, Virginia | Sub | 37.0967° N | 75.9833° W
TEC4305 | Fishermans Rest, Florida | Sub | 29.7333° N | 83.5333° W
8729806 | Fishing Bend, Santa Rosa Sound, Florida | Ref | 30.3367° N | 87.1400° W
8729806 | Fishing Bend, Santa Rosa Sound, Florida (sub) | Sub | 30.3367° N | 87.1400° W
8536848 | Fishing Creek entrance, Delaware Bay, New Jersey | Sub | 39.2167° N | 75.1583° W
9450879 | Fitzgibbon Cove, Alaska | Sub | 55.9833° N | 131.1750° W
8664099 | Five Fathom Creek entrance, Bulls Bay, South Carolina | Sub | 33.0000° N | 79.4967° W
8723644 | Flamingo, Florida Bay, Florida | Sub | 25.1417° N | 80.9233° W
8533780 | Flat Creek, Manahawkin Bay, New Jersey | Sub | 39.7067° N | 74.1917° W
PCT2701_1 | Flat Point , 1 mile east of, Portland Canal, Alaska Current | Sub | 54.9167° N | 130.1667° W
TWC2423 | Flaxman Island, Alaska | Sub | 70.1833° N | 145.8333° W
8636128 | Fleeton Point, Chesapeake Bay, Virginia | Sub | 37.8133° N | 76.2750° W
8724571 | Fleming Key, north end, Florida | Ref | 24.5917° N | 81.7950° W
9434098 | Florence USCG Pier, Suislaw River, Oregon | Ref | 44.0021° N | 124.1230° W
9434032 | Florence, Siuslaw River, Oregon | Sub | 43.9667° N | 124.1030° W
ACT7611_1 | Florida Passage (south) (Depth 6ft), Ossabaw Sound, Georgia Current | Sub | 31.8297° N | 81.1578° W
TEC3425 | Florida Passage, Bear River, Georgia | Sub | 31.8167° N | 81.1667° W
ACT7606_1 | Florida Passage, N of, Ogeechee River (Depth 10ft), Ossabaw Sound, Georgia Current | Sub | 31.8567° N | 81.1433° W
8672219 | Florida Passage, Ogeechee River, Georgia | Sub | 31.8533° N | 81.1467° W
8727386 | Florida Power, Crystal River, Florida | Sub | 28.9600° N | 82.7250° W
8729824 | Floridatown, Escambia Bay, Florida | Ref | 30.5817° N | 87.1800° W
8678642 | Floyd Creek, 2.8 miles above entrance, Georgia | Sub | 30.9367° N | 81.5067° W
8665424 | Folly Creek, Hwy. 171 bridge, South Carolina | Sub | 32.6750° N | 79.9517° W
8630839 | Folly Creek, Metompkin Inlet, Virginia | Sub | 37.6967° N | 75.6350° W
ACT6731_1 | Folly I. Channel, N of Ft. Johnson, Charleston Harbor, South Carolina Current | Sub | 32.7697° N | 79.9012° W
TEC3127 | Folly Island (outer coast), South Carolina | Sub | 32.6500° N | 79.9333° W
ACT6736_1 | Folly Reach, Buoy '5', Charleston Harbor, South Carolina Current | Sub | 32.7763° N | 79.8992° W
8666652 | Folly River Bridge, Folly Island, South Carolina | Sub | 32.6617° N | 79.9450° W
ACT7746_1 | Folly River and Cardigan River, between (Depth 10ft), Doboy Sound, Georgia Current | Sub | 31.4417° N | 81.3367° W
8666467 | Folly River, north, Folly Island, South Carolina | Sub | 32.6700° N | 79.9167° W
8418268 | Fore River, Casco Bay, Maine | Sub | 43.6417° N | 70.2850° W
8532703 | Forge Pond, Metedeconk River, New Jersey | Sub | 40.0650° N | 74.1350° W
8533391 | Forked River, Barnegat Bay, New Jersey | Sub | 39.8250° N | 74.1733° W
9440572 | Fort Canby, Jetty 'A', Washington | Sub | 46.2683° N | 124.0370° W
8659086 | Fort Caswell, Cape Fear River, North Carolina | Sub | 33.8967° N | 78.0167° W
8638017 | Fort Eustis (MARAD), James River, Virginia | Ref | 37.1382° N | 76.6227° W
8668686 | Fort Fremont, Beaufort River, South Carolina | Sub | 32.3067° N | 80.6450° W
8720186 | Fort George Island, Fort George River, Florida | Sub | 30.4400° N | 81.4383° W
8517942 | Fort Hamilton, The Narrows, New York | Sub | 40.6083° N | 74.0350° W
8670678 | Fort Jackson, Savannah River, Georgia | Sub | 32.0817° N | 81.0367° W
8665726 | Fort Johnson, South Carolina | Sub | 32.7517° N | 79.8983° W
1612366 | Fort Kamehameha, Bishop Point, Pearl Harbor, Oahu Island, Hawaii | Ref | 21.3300° N | 157.9670° W
1612366 | Fort Kamehameha, Bishop Point, Pearl Harbor, Oahu Island, Hawaii (sub) | Sub | 21.3300° N | 157.9670° W
ACT6341_1 | Fort Macon, 0.2 mile NE of (Depth 10ft), Beaufort Inlet, North Carolina Current | Sub | 34.6997° N | 76.6753° W
ACT6341_2 | Fort Macon, 0.2 mile NE of (Depth 20ft), Beaufort Inlet, North Carolina Current | Sub | 34.6997° N | 76.6753° W
ACT6336_1 | Fort Macon, 0.6 mile SE of, Beaufort Inlet, North Carolina Current | Sub | 34.6858° N | 76.6683° W
8656571 | Fort Macon, USCG Station, North Carolina | Sub | 34.6983° N | 76.6817° W
8720686 | Fort Matanzas, Matanzas River, ICWW, Florida | Sub | 29.7150° N | 81.2383° W
TEC3419 | Fort McAllister, Ogeechee River, Georgia | Sub | 31.8833° N | 81.2167° W
8574683 | Fort McHenry Marsh, Patapsco River, Maryland | Ref | 39.2617° N | 76.5850° W
8574683 | Fort McHenry Marsh, Patapsco River, Maryland (sub) | Sub | 39.2617° N | 76.5850° W
8729887 | Fort McRee Breakwater, Pensacola Bay, Florida | Sub | 30.3267° N | 87.3117° W
8725520 | Fort Myers, Caloosahatchee River, Florida | Ref | 26.6477° N | 81.8712° W
8725520 | Fort Myers, Caloosahatchee River, Florida (sub) | Sub | 26.6477° N | 81.8712° W
8722213 | Fort Pierce Inlet, Binney Dock, Florida | Ref | 27.4683° N | 80.3000° W
8722212 | Fort Pierce Inlet, south jetty, Florida | Sub | 27.4700° N | 80.2883° W
8414721 | Fort Point, Penobscot River, Maine | Ref | 44.4717° N | 68.8133° W
8423898 | Fort Point, Portsmouth Harbor, New Hampshire | Ref | 43.0714° N | 70.7106° W
8423898 | Fort Point, Portsmouth Harbor, New Hampshire (sub) | Sub | 43.0714° N | 70.7106° W
8419528 | Fort Point, York Harbor, Maine | Sub | 43.1300° N | 70.6383° W
8417177 | Fort Popham, Hunniwell Point, Kennebec River, Maine | Ref | 43.7550° N | 69.7850° W
8417177 | Fort Popham, Hunniwell Point, Kennebec River, Maine (sub) | Sub | 43.7550° N | 69.7850° W
ACT7361_1 | Fort Pulaski, 1.8 miles above, Savannah River, Georgia Current | Sub | 32.0450° N | 80.9317° W
ACT7366_1 | Fort Pulaski, 4.8 miles above, Savannah River, Georgia Current | Sub | 32.0750° N | 80.9767° W
8670870 | Fort Pulaski, Savannah River Entrance, Georgia | Ref | 32.0367° N | 80.9017° W
ACT7356_1 | Fort Pulaski, Savannah River, Georgia Current | Sub | 32.0367° N | 80.9017° W
9416024 | Fort Ross, California | Sub | 38.5133° N | 123.2450° W
ACT6626_1 | Fort Sumter Range, Buoy '14', Charleston Harbor, South Carolina Current | Sub | 32.7243° N | 79.8100° W
ACT6611_1 | Fort Sumter Range, Buoy '2', Charleston Harbor, South Carolina Current | Sub | 32.6830° N | 79.7260° W
ACT6641_1 | Fort Sumter Range, Buoy '20', Charleston Harbor, South Carolina Current | Sub | 32.7405° N | 79.8445° W
ACT6616_1 | Fort Sumter Range, Buoy '4', Charleston Harbor, South Carolina Current | Sub | 32.6977° N | 79.7557° W
ACT6621_1 | Fort Sumter Range, Buoy '8', Charleston Harbor, South Carolina Current | Sub | 32.7150° N | 79.7923° W
8665728 | Fort Sumter, South Carolina | Sub | 32.7533° N | 79.8767° W
8519024 | Fort Wadsworth, The Narrows, Staten Island, New York | Sub | 40.6067° N | 74.0550° W
8536931 | Fortescue Creek, New Jersey | Ref | 39.2383° N | 75.1750° W
9468123 | Fossil River entrance, St. Lawrence Island, Alaska | Sub | 63.4667° N | 170.0170° W
9445016 | Foulweather Bluff, Washington | Ref | 47.9267° N | 122.6170° W
9445016 | Foulweather Bluff, Washington (sub) | Sub | 47.9267° N | 122.6170° W
PCT3101_1 | Found Island, 1 mile northwest of, Zimovia Strait, Alaska Current | Sub | 56.1167° N | 132.1000° W
ACT8671_1 | Four Mile Point, St. Marks River, Apalachee Bay, Florida Current | Sub | 30.1117° N | 84.2033° W
TWC2111 | Fox Bay, Kupreanof Peninsula, Alaska | Sub | 55.6333° N | 159.6167° W
9457361 | Fox Bay, Whale Island, Alaska | Sub | 57.9783° N | 152.7550° W
8630055 | Franklin City, Virginia | Sub | 38.0067° N | 75.3817° W
TEC2937 | Frazier Point, South Carolina | Sub | 33.3167° N | 79.2833° W
ACT6541_1 | Frazier Point, south of, Winyah Bay, South Carolina Current | Sub | 33.2950° N | 79.2728° W
ACT6546_1 | Frazier Point, west of, Winyah Bay, South Carolina Current | Sub | 33.3097° N | 79.2867° W
8676743 | Frederica River, Georgia | Sub | 31.2217° N | 81.3933° W
8677045 | Frederick River Bridge, Georgia | Sub | 31.1683° N | 81.4133° W
9751584 | Fredericksted, St. Croix, Virgin Islands | Ref | 17.7133° N | 64.8833° W
8772471 | Freeport SPIP, Freeport Harbor, Texas | Ref | 28.9357° N | 95.2942° W
8516411 | Freeport, Baldwin Bay, Hempstead Bay, New York | Sub | 40.6333° N | 73.5867° W
8772440 | Freeport, DOW Barge Canal, Texas | Ref | 28.9483° N | 95.3083° W
8772440 | Freeport, DOW Barge Canal, Texas (sub) | Sub | 28.9483° N | 95.3083° W
ACT5891_1 | Freestone Point, 2.3 miles east of, Potomac River, Maryland Current | Sub | 38.5963° N | 77.1980° W
TWC1743 | Freshwater Bay, Chichagof Island, Alaska | Sub | 57.8500° N | 135.0167° W
8766072 | Freshwater Canal Locks, Louisiana | Ref | 29.5517° N | 92.3052° W
9449880 | Friday Harbor, San Juan Island, San Juan Channel, Washington | Ref | 48.5453° N | 123.0129° W
9449880 | Friday Harbor, San Juan Island, San Juan Channel, Washington (sub) | Sub | 48.5453° N | 123.0129° W
8416141 | Friendship Harbor, Maine | Sub | 43.9700° N | 69.3417° W
8668498 | Fripp Inlet, Hunting Island Bridge, St. Helena Sound, South Carolina | Ref | 32.3400° N | 80.4650° W
8668498 | Fripp Inlet, Hunting Island Bridge, St. Helena Sound, South Carolina (sub) | Sub | 32.3400° N | 80.4650° W
ACT7171_1 | Fripps Inlet, Fripps Island (Depth 15ft), South Carolina Current | Sub | 32.3400° N | 80.4650° W
TWC1697 | Fritz Cove, Douglas Island, Alaska | Sub | 58.3167° N | 134.6000° W
ACT7706_1 | Front River (Depth 13ft), Sapelo Sound, Georgia Current | Sub | 31.5133° N | 81.2983° W
ACT6656_1 | Ft. Sumter, 0.6 n.mi. NW of, Charleston Harbor, South Carolina Current | Sub | 32.7612° N | 79.8672° W
8720221 | Fulton, Florida | Sub | 30.3900° N | 81.5067° W
9452321 | Funter, Funter Bay, Lynn Canal, Alaska | Sub | 58.2550° N | 134.8950° W
PCT0081_1 | G St. Pier (San Diego), 0.22 nmi. SW of (Depth 14ft), San Diego Bay, California Current | Sub | 32.7083° N | 117.1775° W
PCT0081_2 | G St. Pier (San Diego), 0.22 nmi. SW of (Depth 37ft), San Diego Bay, California Current | Sub | 32.7083° N | 117.1775° W
8575923 | Galesville, West River, Chesapeake Bay, Maryland | Sub | 38.8417° N | 76.5400° W
8656451 | Gallant Channel, North Carolina | Sub | 34.7283° N | 76.6683° W
9415052 | Gallinas, Gallinas Creek, San Pablo Bay, California | Sub | 38.0150° N | 122.5030° W
8725411 | Galt Island, Pine Island Sound, Florida | Sub | 26.5133° N | 82.1067° W
8771341 | Galveston Bay Entrance, North Jetty, Texas | Ref | 29.3573° N | 94.7248° W
TEC4507 | Galveston Bay entrance, south jetty, Texas | Sub | 29.3333° N | 94.7000° W
8771450 | Galveston Pier 21, Galveston Channel, Texas | Ref | 29.3100° N | 94.7933° W
8771510 | Galveston Pleasure Pier, Gulf Of Mexico, Texas | Ref | 29.2853° N | 94.7894° W
8771510 | Galveston Pleasure Pier, Gulf Of Mexico, Texas (sub) | Sub | 29.2853° N | 94.7894° W
8771486 | Galveston Railroad Bridge, Texas | Ref | 29.3026° N | 94.8971° W
9451906 | Gambier Bay (cannery wharf), Alaska | Sub | 57.4833° N | 133.9600° W
8726641 | Gandy Bridge, Old Tampa Bay, Florida | Sub | 27.8933° N | 82.5383° W
8661419 | Garden City Bridge, Main Creek, Murrells Inlet, South Carolina | Ref | 33.5783° N | 79.0033° W
8661437 | Garden City Pier (ocean), South Carolina | Ref | 33.5750° N | 78.9967° W
8723622 | Garden Cove, Key Largo, Florida | Sub | 25.1717° N | 80.3667° W
8724697 | Garden Key, Dry Tortugas, Florida | Sub | 24.6267° N | 82.8717° W
9444705 | Gardiner, Discovery Bay, Strait of Juan de Fuca, Washington | Sub | 48.0583° N | 122.9170° W
8417134 | Gardiner, Kennebec River, Maine | Ref | 44.2333° N | 69.7667° W
TWC0831 | Gardiner, Umpqua River, Oregon | Sub | 43.7333° N | 124.1167° W
TWC2297 | Gareloi Island, Delarof Islands, Alaska | Sub | 51.7500° N | 178.8000° W
8630637 | Gargathy Neck, Virginia | Sub | 37.7767° N | 75.5617° W
9437540 | Garibaldi, Tillamook Bay, Oregon | Ref | 45.5545° N | 123.9189° W
9437540 | Garibaldi, Tillamook Bay, Oregon (sub) | Sub | 45.5545° N | 123.9189° W
8410715 | Garnet Point, Hersey Neck, Pennamquan River, Cobscook Bay, Maine | Ref | 44.9233° N | 67.1300° W
8410715 | Garnet Point, Hersey Neck, Pennamquan River, Cobscook Bay, Maine (sub) | Sub | 44.9233° N | 67.1300° W
8632869 | Gaskins Point, Occohannock Creek, Chesapeake Bay, Virginia | Ref | 37.5567° N | 75.9167° W
8632869 | Gaskins Point, Occohannock Creek, Chesapeake Bay, Virginia (sub) | Sub | 37.5567° N | 75.9167° W
ACT8346_1 | Gasparilla Pass, Florida Current | Sub | 26.8123° N | 82.2810° W
8741798 | Gautier, Mississippi | Ref | 30.3833° N | 88.6100° W
9411399 | Gaviota State Park, California | Ref | 34.4694° N | 120.2283° W
ACT1866_1 | Gay Head, 1.5 miles northwest of, Vineyard Sound, Massachusetts Current | Sub | 41.3633° N | 70.8633° W
ACT1861_1 | Gay Head, 3 miles north of, Vineyard Sound, Massachusetts Current | Sub | 41.4017° N | 70.8533° W
ACT1851_1 | Gay Head, 3 miles northeast of, Vineyard Sound, Massachusetts Current | Sub | 41.3850° N | 70.7833° W
8448733 | Gay Head, Martha's Vineyard, Massachusetts | Sub | 41.3533° N | 70.8300° W
9457726 | Geese Island GPS Tide Buoy, Alaska | Ref | 56.5947° N | 153.9960° W
8664022 | General Dynamics Pier, Cooper River, South Carolina | Ref | 33.0083° N | 79.9233° W
8664022 | General Dynamics Pier, Cooper River, South Carolina (sub) | Sub | 33.0083° N | 79.9233° W
9413617 | General Fish Company Pier, Moss Landing, Monterey Bay, California | Sub | 36.8017° N | 121.7870° W
8662747 | Georgetown Lighthouse, South Carolina | Sub | 33.2233° N | 79.1850° W
8662926 | Georgetown, Sampit River, South Carolina | Sub | 33.3617° N | 79.2800° W
ACT6561_1 | Georgetown, Sampit River, Winyah Bay, South Carolina Current | Sub | 33.3592° N | 79.2875° W
ACT6211_1 | Georgetown, Sassafrass River, Maryland Current | Sub | 39.3612° N | 75.8862° W
9415287 | Georgiana Slough entrance, Mokelumne River, California | Sub | 38.1250° N | 121.5780° W
8419688 | Gerrish Island, Portsmouth Harbor, New Hampshire | Sub | 43.0667° N | 70.6967° W
TWC2305 | Gertrude Cove, Kiska Island, Rat Islands, Alaska | Sub | 51.9333° N | 177.4500° E
9454573 | Gibbon Anchorage, Green Island, Prince William Sound, Alaska | Sub | 60.2700° N | 147.4380° W
9446369 | Gig Harbor, Puget Sound, Washington | Sub | 47.3400° N | 122.5880° W
TEC4525 | Gilchrist, East Bay, Galveston Bay, Texas | Sub | 29.5167° N | 94.4833° W
8515764 | Gilgo Heading, Great South Bay, New York | Sub | 40.6200° N | 73.3950° W
8575550 | Gingerville Creek, South River, Chesapeake Bay, Maryland | Sub | 38.9583° N | 76.5550° W
8636046 | Glebe Point, Great Wicomico River, Chesapeake Bay, Virginia | Sub | 37.8467° N | 76.3683° W
8516614 | Glen Cove Yacht Club, Hempstead Harbor, Long Island, New York | Ref | 40.8633° N | 73.6550° W
8516614 | Glen Cove Yacht Club, Hempstead Harbor, Long Island, New York (sub) | Sub | 40.8633° N | 73.6550° W
9447814 | Glendale, Whidbey Island, Washington | Sub | 47.9400° N | 122.3570° W
8441841 | Gloucester Harbor, Massachusetts | Sub | 42.6100° N | 70.6600° W
8637624 | Gloucester Point, York River, Virginia | Ref | 37.2467° N | 76.5000° W
8637624 | Gloucester Point, York River, Virginia (sub) | Sub | 37.2467° N | 76.5000° W
9431011 | Gold Beach, Rogue River, Oregon | Ref | 42.4216° N | 124.4187° W
9414551 | Gold Street Bridge, Alviso Slough, San Francisco Bay, California | Sub | 37.4233° N | 121.9750° W
8723026 | Golden Beach, ICWW, Florida | Sub | 25.9667° N | 80.1250° W
ACT8386_1 | Golden Gate Point, off, Sarasota Bay, Florida Current | Sub | 27.3283° N | 82.5567° W
8762184 | Golden Meadow, Plaisance Canal, Louisiana | Ref | 29.3733° N | 90.2650° W
9451421 | Golf Island, Necker Islands, Alaska | Ref | 56.7867° N | 135.3930° W
8722414 | Gomez, South Jupiter Narrows, Florida | Sub | 27.0933° N | 80.1367° W
8669346 | Good Hope Landing, south of, New River, South Carolina | Sub | 32.1767° N | 80.9667° W
9451909 | Good Island, Gambier Bay, Alaska | Sub | 57.4867° N | 133.8980° W
9469833 | Goodhope Bay, Kotzebue Sound, Alaska | Ref | 66.2303° N | 163.9041° W
9465368 | Goodnews Bay entrance, Alaska | Sub | 59.0450° N | 161.8080° W
PCT5821_1 | Goodnews Bay entrance, Kuskokwim Bay, Alaska Current | Sub | 59.0667° N | 161.7833° W
8637686 | Goodwin Neck, Yorktown, York River, Virginia | Sub | 37.2300° N | 76.4367° W
8533005 | Goose Creek entrance, Barnegat Bay, New Jersey | Sub | 39.9633° N | 74.1150° W
9455963 | Goose Creek, Knik Arm, Cook Inlet, Alaska | Ref | 61.3933° N | 149.8470° W
8578769 | Goose Creek, Port Tobacco River, Potomac River, Maryland | Sub | 38.4533° N | 77.0533° W
9449184 | Gooseberry Point, Hale Passage, Washington | Sub | 48.7300° N | 122.6700° W
8531925 | Gooseneck Point, bridge, Shrewsbury River, New Jersey | Sub | 40.3267° N | 74.0167° W
8724306 | Gopher Key, Cudjoe Bay, Florida | Sub | 24.6417° N | 81.4850° W
ACT7036_1 | Goshen Point, SE of, Wadmalaw River (Depth 12ft), South Carolina Current | Sub | 32.7100° N | 80.1717° W
ACT7041_1 | Goshen Point, south of, Wadmalaw River (Depth 12ft), South Carolina Current | Sub | 32.7133° N | 80.1867° W
8427031 | Gosport Harbor, Isles of Shoals, New Hampshire | Sub | 42.9783° N | 70.6150° W
ACT2136_1 | Gould Island, southeast of (Depth 7ft), Narragansett Bay, Rhode Island Current | Sub | 41.5250° N | 71.3367° W
ACT2141_1 | Gould Island, west of (Depth 15ft), Narragansett Bay, Rhode Island Current | Sub | 41.5317° N | 71.3583° W
8723178 | Government Cut, Miami Harbor Entrance, Florida | Ref | 25.7633° N | 80.1300° W
8517921 | Gowanus Bay, New York | Sub | 40.6650° N | 74.0133° W
8660315 | Grahamville, Waccamaw River, South Carolina | Sub | 33.8300° N | 78.9533° W
8740166 | Grand Bay NERR, Mississippi Sound, Mississippi | Ref | 30.4132° N | 88.4029° W
PCT3236_1 | Grand Island, 2 miles north of, Tlevak Strait, Alaska Current | Sub | 55.0000° N | 132.8667° W
8761720 | Grand Isle, Mississippi River Delta, Louisiana | Ref | 29.2550° N | 89.9683° W
8761724 | Grand Isle, Mississippi River Delta, Louisiana (2) | Ref | 29.2633° N | 89.9567° W
8760668 | Grand Pass, Louisiana | Ref | 30.1267° N | 89.2217° W
9414513 | Granite Rock, Redwood Creek, San Francisco Bay, California | Sub | 37.4950° N | 122.2130° W
9414785 | Grant Line Canal (drawbridge), San Joaquin River, California | Sub | 37.8200° N | 121.4470° W
9463058 | Grant Point, Izembek Lagoon, Bristol Bay, Alaska | Sub | 55.2700° N | 162.9000° W
PCT2961_1 | Grass Rock, 1 mile south of, Clarence Strait, Alaska Current | Sub | 55.0000° N | 131.5500° W
PCT2836_1 | Grass Rock, Tamgas Harbor entrance, Felice Strait, Alaska Current | Sub | 55.0217° N | 131.5223° W
8723921 | Grassy Key, north side, Florida Bay, Florida | Sub | 24.7717° N | 80.9400° W
8723933 | Grassy Key, south side, Hawk Channel, Florida | Sub | 24.7550° N | 80.9583° W
TWC1875 | Gravel Point, Orca Inlet, Alaska | Sub | 60.4667° N | 145.9667° W
8742205 | Graveline Bayou entrance, Mississippi | Ref | 30.3617° N | 88.6633° W
8534244 | Graveling Point, Great Bay, New Jersey | Sub | 39.5400° N | 74.3867° W
8410864 | Gravelly Point, Whiting Bay, Maine | Ref | 44.8233° N | 67.1517° W
9452704 | Graves Harbor, Alaska | Sub | 58.2767° N | 136.6780° W
8447295 | Gray Gables, Buzzards Bay, Massachusetts | Ref | 41.7350° N | 70.6233° W
8447295 | Gray Gables, Buzzards Bay, Massachusetts (sub) | Sub | 41.7350° N | 70.6233° W
PCT1291_1 | Grays Harbor Entrance, Washington Current | Ref | 46.9225° N | 124.1330° W
8417881 | Great Chebeague Island, Casco Bay, Maine | Sub | 43.7217° N | 70.1417° W
8417988 | Great Diamond Island, Casco Bay, Maine | Sub | 43.6700° N | 70.2000° W
8447368 | Great Hill, Buzzards Bay, Massachusetts | Ref | 41.7117° N | 70.7150° W
8447368 | Great Hill, Buzzards Bay, Massachusetts (sub) | Sub | 41.7117° N | 70.7150° W
8519436 | Great Kills Harbor, New Jersey | Ref | 40.5433° N | 74.1400° W
8631411 | Great Machipongo Inlet (inside), Virginia | Sub | 37.3933° N | 75.7133° W
8722381 | Great Pocket, Florida | Sub | 27.1550° N | 80.1717° W
ACT1666_1 | Great Point, 0.5 mile west of, Nantucket Sound, Massachusetts Current | Sub | 41.3933° N | 70.0617° W
ACT1671_1 | Great Point, 3 miles west of, Nantucket Sound, Massachusetts Current | Sub | 41.3900° N | 70.1133° W
8448566 | Great Point, Nantucket Island, Massachusetts | Sub | 41.3867° N | 70.0467° W
8514783 | Great River, Connetquot River, Great South Bay, New York | Sub | 40.7233° N | 73.1517° W
8571416 | Great Shoals Light, Monie Bay, Chesapeake Bay, Maryland | Sub | 38.2167° N | 75.8833° W
8636142 | Great Wicomico River Light, Chesapeake Bay, Virginia | Sub | 37.8050° N | 76.2683° W
9452133 | Greely Point, Taku Inlet, Alaska | Sub | 58.2233° N | 134.0600° W
8534117 | Green Bank, Mullica River, New Jersey | Sub | 39.6117° N | 74.5900° W
9462705 | Green Bight, Akutan Island, Aleutian Islands, Alaska | Ref | 54.1103° N | 165.6614° W
8720496 | Green Cove Springs, Florida | Sub | 29.9900° N | 81.6633° W
9416409 | Green Cove, California | Ref | 38.7043° N | 123.4494° W
8516155 | Green Island, Hempstead Bay, New York | Ref | 40.6233° N | 73.5017° W
8516155 | Green Island, Hempstead Bay, New York (sub) | Sub | 40.6233° N | 73.5017° W
8412568 | Green Island, Petit Manan Bar, Maine | Sub | 44.3717° N | 67.8700° W
PCT3781_1 | Green Point, Wrangell Narrows, Alaska Current | Sub | 56.7000° N | 132.9500° W
9447883 | Greenbank, Whidbey Island, Washington | Ref | 48.1050° N | 122.5700° W
ACT6106_1 | Greenbury Point, 1.8 miles east of (Depth 8ft), Maryland Current | Sub | 38.9733° N | 76.4167° W
9440650 | Greenhead Slough, Washington | Ref | 46.3722° N | 123.9503° W
8511907 | Greenport, Shelter Island Sound, New York | Ref | 41.1010° N | 72.3612° W
8537374 | Greenwich Pier, Cohansey River, Delaware Bay, New Jersey | Sub | 39.3833° N | 75.3500° W
8664532 | Greggs Landing, Matceba Gardens, Ashley River, South Carolina | Sub | 32.9317° N | 80.1567° W
9451238 | Greys Island, Alaska | Sub | 56.5217° N | 132.5420° W
8414581 | Gross Point, Eastern Channel, Penobscot River, Maine | Sub | 44.5367° N | 68.7583° W
ACT5131_1 | Grove Point, 0.7 n.mi.NW of (Depth 14ft), Chesapeake Bay, Maryland Current | Sub | 39.3963° N | 76.0503° W
ACT6201_1 | Grove Point, Sassafrass River, Maryland Current | Sub | 39.3783° N | 76.0433° W
TEC4731 | Guanica, Puerto Rico | Sub | 17.9667° N | 66.9167° W
PCT3011_1 | Guard Island Lighthouse, 5.1 miles SW of, Clarence Strait, Alaska Current | Sub | 55.4000° N | 132.0000° W
PCT2946_1 | Guard Islands, 2 miles northwest of, Behm Canal, Alaska Current | Sub | 55.4667° N | 131.9000° W
PCT3016_1 | Guard Islands, 2 miles west of, Clarence Strait, Alaska Current | Sub | 55.4500° N | 131.9500° W
8633596 | Guard Shore, Chesapeake Bay, Virginia | Sub | 37.8500° N | 75.7000° W
9454751 | Guguak, Alaska | Ref | 60.1000° N | 148.0380° W
9454751 | Guguak, Alaska (sub) | Sub | 60.1000° N | 148.0380° W
8464445 | Guilford Harbor, Connecticut | Sub | 41.2717° N | 72.6667° W
8466375 | Gulf Beach, Connecticut | Sub | 41.2050° N | 73.0417° W
8726995 | Gulf Harbors, Florida | Sub | 28.2433° N | 82.7633° W
8731439 | Gulf Shores, ICWW, Alabama | Ref | 30.2799° N | 87.6843° W
8726486 | Gulfport, Boca Ciega Bay, Florida | Sub | 27.7367° N | 82.7067° W
8745557 | Gulfport, Gulfport Harbor, Mississippi | Ref | 30.3600° N | 89.0817° W
8745557 | Gulfport, Gulfport Harbor, Mississippi (sub) | Sub | 30.3600° N | 89.0817° W
ACT6191_1 | Gunpowder River entrance, Maryland Current | Sub | 39.3117° N | 76.3083° W
8530278 | Hackensack, Hackensack River, New Jersey | Sub | 40.8800° N | 74.0400° W
8463582 | Haddam, Connecticut River, Connecticut | Sub | 41.4817° N | 72.5067° W
8463155 | Hadlyme, Connecticut River, Connecticut | Sub | 41.4200° N | 72.4283° W
ACT6871_1 | Hagan Island, 1 n.mi. below, Cooper River, Charleston Harbor, South Carolina Current | Sub | 33.0333° N | 79.9133° W
9465234 | Hagemeister Island (north end), Alaska | Ref | 58.7767° N | 160.7770° W
8661991 | Hagley Landing, Waccamaw River, South Carolina | Sub | 33.4350° N | 79.1817° W
PCT5761_1 | Hague Channel, east of Doe Point, Alaska Current | Sub | 55.9000° N | 160.7667° W
ACT7291_1 | Haig Point Light, NW of, Cooper River (Depth 10ft), South Carolina Current | Sub | 32.1483° N | 80.8417° W
8669493 | Haig Point, Daufuskie Island, Cooper River, South Carolina | Sub | 32.1467° N | 80.8367° W
ACT6136_1 | Hail Point, 0.7 n.mi.east of (Depth 16ft), Chester River, Maryland Current | Sub | 39.0105° N | 76.1825° W
9452435 | Haines Inlet, Lynn Canal, Alaska | Sub | 59.2300° N | 135.4330° W
8538824 | Hainesport, South Branch, Rancocas Creek, New Jersey | Sub | 39.9783° N | 74.8233° W
ACT5906_1 | Hains Point, Potomac River, DC Current | Sub | 38.8513° N | 77.0220° W
1612668 | Haleiwa, Waialua Bay, Oahu Island, Hawaii | Sub | 21.5983° N | 158.1080° W
9451826 | Haley Anchorage, Fish Bay, Alaska | Sub | 57.3717° N | 135.6180° W
9433445 | Halfmoon Bay, Umpqua River, Oregon | Ref | 43.6750° N | 124.1920° W
8720093 | Halfmoon Island, highway bridge, Nassau River, Florida | Sub | 30.5767° N | 81.6083° W
8671314 | Halfmoon Reef, Halfmoon River, Georgia | Ref | 31.9633° N | 80.9433° W
ACT1656_1 | Halfmoon Shoal, 1.9 miles northeast of, Nantucket Sound, Massachusetts Current | Sub | 41.4842° N | 70.1925° W
ACT1661_1 | Halfmoon Shoal, 3.5 miles east of, Nantucket Sound, Massachusetts Current | Sub | 41.4683° N | 70.1533° W
8673381 | Halfmoon, Timmons River, Georgia | Sub | 31.6950° N | 81.2717° W
9455556 | Halibut Cove, Kachemak Bay, Cook Inlet, Alaska | Sub | 59.5967° N | 151.2200° W
ACT5896_1 | Hallowing Point, Potomac River, Maryland Current | Sub | 38.6450° N | 77.1275° W
8727293 | Halls River bridge, Homosassa River, Florida | Ref | 28.8000° N | 82.6033° W
8727293 | Halls River bridge, Homosassa River, Florida (sub) | Sub | 28.8000° N | 82.6033° W
8665387 | Hamlin Creek, Isle of Palms, South Carolina | Sub | 32.7867° N | 79.7917° W
8665167 | Hamlin Sound, South Carolina | Sub | 32.8267° N | 79.7867° W
9439011 | Hammond, Oregon | Ref | 46.2017° N | 123.9450° W
PCT1151_1 | Hammond, northeast of ship channel (Depth 15ft), Oregon Current | Sub | 46.2112° N | 123.9345° W
8429489 | Hampton Harbor, New Hampshire | Sub | 42.8950° N | 70.8167° W
TEC3495 | Hampton River entrance, Georgia | Sub | 31.2167° N | 81.3167° W
1615395 | Hana, Maui Island, Hawaii | Sub | 20.7617° N | 155.9870° W
8664589 | Hanahan, Turkey Creek, Goose Creek, Cooper River, South Carolina | Sub | 32.9183° N | 80.0117° W
1611683 | Hanalei Bay, Kauai Island, Hawaii | Sub | 22.2150° N | 159.5020° W
1611443 | Hanamaulu Bay, Kauai Island, Hawaii | Sub | 21.9950° N | 159.3350° W
1612301 | Hanauma Bay, Oahu Island, Hawaii | Sub | 21.2750° N | 157.6970° W
9449828 | Hanbury Point, Mosquito Pass, San Juan I., Haro Strait, Washington | Ref | 48.5817° N | 123.1700° W
ACT1651_1 | Handkerchief Lighted Whistle Buoy 'H', Nantucket Sound, Massachusetts Current | Sub | 41.4883° N | 70.0667° W
8745101 | Handsboro Bridge, Bernard Bayou, Mississippi | Ref | 30.4067° N | 89.0267° W
TWC1893 | Hanning Bay, Montague Island, Alaska | Sub | 59.9500° N | 147.6833° W
9445526 | Hansville, Puget Sound, Washington | Sub | 47.9183° N | 122.5450° W
PCT0061_1 | Harbor Island (east end), SSW of (Depth 15ft), San Diego Bay, California Current | Sub | 32.7192° N | 117.1917° W
ACT8476_1 | Harbor Key, 1.3 miles west of, Tampa Bay, Florida Current | Sub | 27.6112° N | 82.5945° W
PCT5756_1 | Harbor Point, Port Moller, Alaska Current | Sub | 55.9167° N | 160.6000° W
8668146 | Harbor River Bridge, St. Helena Sound, South Carolina | Sub | 32.4033° N | 80.4533° W
8663899 | Harbor River entrance, Bulls Bay, South Carolina | Sub | 33.0333° N | 79.5350° W
8630316 | Harbor of Refuge, Virginia | Sub | 37.9033° N | 75.4067° W
8633091 | Harborton, Pungoteague Creek, Chesapeake Bay, Virginia | Sub | 37.6667° N | 75.8333° W
8725791 | Harbour Heights, Peace River, Charlotte Harbor, Florida | Ref | 26.9883° N | 81.9933° W
8669722 | Hargray Pier, Daufuskie Island, New River, South Carolina | Sub | 32.0983° N | 80.8983° W
8656503 | Harkers Island Bridge, North Carolina | Sub | 34.7150° N | 76.5783° W
8518643 | Harlem River, Randalls Island, East River, New York | Ref | 40.8000° N | 73.9283° W
9445993 | Harper, Yukon Harbor, Puget Sound, Washington | Sub | 47.5233° N | 122.5170° W
8679083 | Harrietts Bluff, Crooked River, Georgia | Sub | 30.8700° N | 81.5850° W
TWC0895 | Harrington Point, Washington | Sub | 46.2667° N | 123.6500° W
PCT2816_1 | Harris Island, Felice Strait, Alaska Current | Sub | 55.0000° N | 131.5333° W
8673962 | Harris Neck, Barbour Island River, Georgia | Sub | 31.6233° N | 81.2633° W
8729613 | Harris, The Narrows, Florida | Sub | 30.4083° N | 86.7317° W
8516607 | Harry Tappen Marina, Hempstead Harbor, Long Island, New York | Ref | 40.8346° N | 73.6524° W
8464464 | Hartford, Connecticut River, Connecticut | Sub | 41.7700° N | 72.6683° W
8512053 | Hashamomuck Beach, Long Island, New York | Sub | 41.0950° N | 72.3983° W
8654467 | Hatteras (USCG Station), North Carolina | Ref | 35.2086° N | 75.7042° W
8654467 | Hatteras (USCG Station), North Carolina (sub) | Sub | 35.2086° N | 75.7042° W
TEC2791 | Hatteras Inlet, North Carolina | Sub | 35.2000° N | 75.7333° W
ACT6286_1 | Hatteras Inlet, Pamlico Sound, North Carolina Current | Sub | 35.2000° N | 75.7500° W
8723080 | Haulover Pier, N. Miami Beach, Florida | Ref | 25.9033° N | 80.1200° W
8723080 | Haulover Pier, N. Miami Beach, Florida (sub) | Sub | 25.9033° N | 80.1200° W
8518924 | Haverstraw Bay, Hudson River, New York | Ref | 41.2183° N | 73.9633° W
8518924 | Haverstraw Bay, Hudson River, New York (sub) | Sub | 41.2183° N | 73.9633° W
8574070 | Havre de Grace, Susquehanna River, Maryland | Ref | 39.5367° N | 76.0900° W
8574070 | Havre de Grace, Susquehanna River, Maryland (sub) | Sub | 39.5367° N | 76.0900° W
9452294 | Hawk Inlet Entrance, Alaska | Ref | 58.0850° N | 134.7770° W
9452294 | Hawk Inlet Entrance, Alaska (sub) | Sub | 58.0850° N | 134.7770° W
8574821 | Hawkins Point, Patapsco River, Maryland | Sub | 39.2083° N | 76.5333° W
8729753 | Hawkins Recreational Park, Blackwater River, Florida | Ref | 30.6367° N | 87.0283° W
8638478 | Haxall, James River, Virginia | Sub | 37.3733° N | 77.2433° W
PCT2671_1 | Haystack Island, Tongass Passage, Pearse Canal, Alaska Current | Sub | 54.7167° N | 130.6167° W
PCT4056_1 | Hazy Islands, Chatham Strait, Alaska Current | Sub | 55.8833° N | 134.6000° W
PCT1071_1 | Heceta Head, Oregon Current | Sub | 44.1333° N | 124.1333° W
ACT1766_1 | Hedge Fence Lighted Gong Buoy 22, Nantucket Sound, Massachusetts Current | Sub | 41.4717° N | 70.4833° W
ACT1806_1 | Hedge Fence-L'Hommedieu Shoal, between, Nantucket Sound, Massachusetts Current | Sub | 41.5050° N | 70.5367° W
ACT3401_1 | Hell Gate (off Mill Rock), New York Current | Ref | 40.7783° N | 73.9383° W
8517401 | Hell Gate, Wards Island, East River, New York | Sub | 40.7867° N | 73.9217° W
PCT2941_1 | Helm Point, Behm Canal, Alaska Current | Sub | 55.6000° N | 131.8333° W
9466153 | Helmick Point (SE of), Kuskokwim River, Alaska | Ref | 60.2703° N | 162.4102° W
9446752 | Henderson Inlet, Puget Sound, Washington | Sub | 47.1550° N | 122.8380° W
ACT6226_1 | Hendersons Point, Elk River, Maryland Current | Sub | 39.5533° N | 75.8600° W
8725377 | Hendry Creek, Estero Bay, Florida | Ref | 26.4700° N | 81.8767° W
ACT3511_1 | Henry Hudson Bridge, 0.7 nmi. SE of (Depth 16ft), Harlem River, New York Current | Sub | 40.8767° N | 73.9217° W
ACT6281_1 | Herbert C. Bonner Bridge, WSW of (Depth 6ft), Oregon Inlet, North Carolina Current | Sub | 35.7700° N | 75.5467° W
TWC2223 | Herbert Island, west side, Aleutian Islands, Alaska | Sub | 52.7167° N | 170.1500° W
9415074 | Hercules, Refugio Landing, San Pablo Bay, California | Sub | 38.0233° N | 122.2920° W
9459163 | Herendeen Island, Shumagin Islands, Alaska | Ref | 55.0656° N | 159.4187° W
8729791 | Hernandez Point North, Florida | Ref | 30.4550° N | 87.1000° W
8727122 | Hernando Beach, Rocky Creek, Little Pine I. Bay, Florida | Sub | 28.4867° N | 82.6617° W
9451634 | Herring Bay, Frederick Sound, Alaska | Sub | 57.1133° N | 134.3800° W
9454691 | Herring Point, Knight Island, Prince William Sound, Alaska | Ref | 60.4750° N | 147.7920° W
9454691 | Herring Point, Knight Island, Prince William Sound, Alaska (sub) | Sub | 60.4750° N | 147.7920° W
PCT2871_1 | Hid Reef, 2.7 miles south of, Nichols Passage, Alaska Current | Sub | 55.0333° N | 131.6667° W
8463836 | Higganum Creek, Connecticut River, Connecticut | Sub | 41.5033° N | 72.5533° W
8533631 | High Bar, Barnegat Bay, New Jersey | Sub | 39.7567° N | 74.1283° W
ACT3496_1 | High Bridge, Harlem River, New York Current | Sub | 40.8417° N | 73.9317° W
8770808 | High Island (TCOON), Texas | Ref | 29.5947° N | 94.3903° W
PCT3721_1 | High Island, 1.1 miles south of, Keku Strait, Alaska Current | Sub | 56.7023° N | 133.7330° W
9465173 | High Island, Bristol Bay, Alaska | Ref | 58.7217° N | 160.4270° W
PCT3726_1 | High Island, northwest of, Keku Strait, Alaska Current | Sub | 56.7500° N | 133.7333° W
PCT3241_1 | High Point, 1 mile east of, Tlevak Strait, Alaska Current | Sub | 55.0167° N | 132.9333° W
8531712 | Highlands, Route 36 bridge, Shrewsbury River, New Jersey | Sub | 40.3967° N | 73.9817° W
PCT4216_1 | Highwater Island, west of, Neva Strait, Alaska Current | Sub | 57.2833° N | 135.6000° W
ACT6946_1 | Highway Bridge, Ashley River, Charleston Harbor, South Carolina Current | Sub | 32.7820° N | 79.9600° W
PCT1081_1 | Highway Bridge, Yaquina Bay, Oregon Current | Sub | 44.6233° N | 124.0570° W
TEC3421 | Highway bridge, Ogeechee River, Georgia | Sub | 31.9833° N | 81.2833° W
TEC3521 | Highway bridge, South Brunswick River, Georgia | Sub | 31.1500° N | 81.5667° W
8722854 | Hillsboro Beach, ICWW, Florida | Sub | 26.2733° N | 80.0800° W
8722862 | Hillsboro Inlet (ocean), Florida | Sub | 26.2567° N | 80.0800° W
8722859 | Hillsboro Inlet Marina, Florida | Ref | 26.2600° N | 80.0850° W
8722861 | Hillsboro Inlet, Coast Guard Light Station, Florida | Sub | 26.2583° N | 80.0817° W
8572669 | Hillsboro, Tuckahoe Creek, Maryland | Ref | 38.9167° N | 75.9450° W
8572669 | Hillsboro, Tuckahoe Creek, Maryland (sub) | Sub | 38.9167° N | 75.9450° W
1617760 | Hilo, Hilo Bay, Kuhio Bay, Hawaii Island, Hawaii | Ref | 19.7303° N | 155.0556° W
ACT7201_1 | Hilton Head, Port Royal Sound, South Carolina Current | Sub | 32.2500° N | 80.6667° W
8444775 | Hingham, Massachusetts | Sub | 42.2467° N | 70.8850° W
8447791 | Hix Bridge, East Branch, Westport River, Massachusetts | Sub | 41.5700° N | 71.0733° W
8666918 | Ho-Non-Wah Boy Scout Camp, Bohicket Creek, North Edisto River, South Carolina | Sub | 32.6250° N | 80.1667° W
9451851 | Hobart Bay, Alaska | Sub | 57.4067° N | 133.4200° W
8665192 | Hobcaw Point, Wando River, South Carolina | Sub | 32.8217° N | 79.9000° W
8722429 | Hobe Sound bridge, Florida | Sub | 27.0650° N | 80.1233° W
8722445 | Hobe Sound, Jupiter Island, Florida | Sub | 27.0367° N | 80.1067° W
8660266 | Hog Inlet Pier, South Carolina | Sub | 33.8367° N | 78.6067° W
ACT6726_1 | Hog Island Channel, Charleston Harbor, South Carolina Current | Sub | 32.7812° N | 79.8763° W
ACT6751_1 | Hog Island Reach, Buoy '12', Charleston Harbor, South Carolina Current | Sub | 32.7945° N | 79.9150° W
ACT6766_1 | Hog Island Reach, SW of Remley Point, Charleston Harbor, South Carolina Current | Sub | 32.8118° N | 79.9120° W
9415344 | Hog Island, San Antonio Creek, San Pablo Bay, California | Sub | 38.1617° N | 122.5500° W
ACT2171_1 | Hog Island, northwest of (Depth 10ft), Narragansett Bay, Rhode Island Current | Sub | 41.6467° N | 71.2950° W
ACT5931_1 | Hog Point, 0.6 n.mi. north of (Depth 13ft), Patuxent River, Maryland Current | Sub | 38.3180° N | 76.4012° W
ACT5931_2 | Hog Point, 0.6 n.mi. north of (Depth 41ft), Patuxent River, Maryland Current | Sub | 38.3180° N | 76.4012° W
9454805 | Hogg Bay, Port Bainbridge, Prince William Sound, Alaska | Sub | 60.0767° N | 148.1950° W
9452067 | Holkham Bay, Tracy Arm Entrance, Alaska | Sub | 57.7600° N | 133.6030° W
9452064 | Holkham Bay, Wood Spit, Alaska | Sub | 57.7183° N | 133.5780° W
8571214 | Holland Island Bar Light, Chesapeake Bay, Maryland | Sub | 38.0683° N | 76.0967° W
ACT4936_1 | Holland Point, 2.0 n.mi east of (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 38.7517° N | 76.4988° W
ACT5986_1 | Holland Point, 2.0 n.mi. SSW of (Depth 14ft), Choptank River, Maryland Current | Sub | 38.6738° N | 76.2575° W
8638409 | Hollidays Point (Kings Highway bridge), Nansemond River, Virginia | Sub | 36.8383° N | 76.5500° W
8743081 | Hollingsworth Point, Davis Bayou, Mississippi | Ref | 30.3867° N | 88.7733° W
8743081 | Hollingsworth Point, Davis Bayou, Mississippi (sub) | Sub | 30.3867° N | 88.7733° W
9450544 | Hollis Anchorage, Kasaan Bay, Alaska | Sub | 55.4800° N | 132.6450° W
9447855 | Holly Farms Harbor, Holmes Harbor, Whidbey I., Washington | Sub | 48.0267° N | 122.5350° W
8661558 | Holly Grove Plantation, Great Pee Dee River, South Carolina | Sub | 33.5517° N | 79.1767° W
8722979 | Hollywood Beach, Florida | Sub | 26.0400° N | 80.1150° W
8537026 | Hollywood Beach, The Glades, Delaware Bay, New Jersey | Sub | 39.2750° N | 75.1417° W
8722977 | Hollywood Beach, West Lake, north end, Florida | Sub | 26.0433° N | 80.1267° W
8722982 | Hollywood Beach, West Lake, south end, Florida | Sub | 26.0333° N | 80.1233° W
9414866 | Holt, Whiskey Slough, San Joaquin River, California | Sub | 37.9350° N | 121.4350° W
TWC2317 | Holtz Bay, Attu Island, Alaska | Sub | 52.9167° N | 173.1667° E
9446500 | Home, Von Geldern Cove, Carr Inlet, Puget Sound, Washington | Sub | 47.2750° N | 122.7580° W
9455557 | Homer, Kachemak Bay, Cook Inlet, Alaska | Sub | 59.6033° N | 151.4200° W
1612340 | Honolulu, Honolulu Harbor, Oahu Island, Hawaii | Ref | 21.3067° N | 157.8670° W
1618578 | Honuapo, Hawaii Island, Hawaii | Sub | 19.0883° N | 155.5530° W
9418686 | Hookton Slough, Humboldt Bay, California | Sub | 40.6867° N | 124.2220° W
9452438 | Hoonah, Port Fredrick, Alaska | Ref | 58.1076° N | 135.4442° W
PCT5866_1 | Hooper Bay entrance, Alaska Current | Sub | 61.5000° N | 166.0500° W
8571402 | Hooper Strait Light, Chesapeake Bay, Maryland | Sub | 38.2267° N | 76.0767° W
8537667 | Hope Creek, 0.6 n.mi. above entrance, Delaware River, New Jersey | Sub | 39.4583° N | 75.4950° W
8666167 | Hope Creek, Edisto River, South Edisto River, South Carolina | Sub | 32.7000° N | 80.4267° W
8638481 | Hopewell, City Point, James River, Virginia | Ref | 37.3133° N | 77.2700° W
8635171 | Hopyard Landing, Rappahannock River, Virginia | Sub | 38.2433° N | 77.2267° W
ACT6916_1 | Horlbeck Creek, 0.2 mile above entrance, Wando River, South Carolina Current | Sub | 32.8850° N | 79.8450° W
ACT6931_1 | Horlbeck Creek, 2.5 miles north of, Wando River, South Carolina Current | Sub | 32.9183° N | 79.8383° W
8742221 | Horn Island, Mississippi Sound, Mississippi | Ref | 30.2383° N | 88.6667° W
8742221 | Horn Island, Mississippi Sound, Mississippi (sub) | Sub | 30.2383° N | 88.6667° W
8518668 | Horns Hook, East 90th Street, East River, New York, New York | Ref | 40.7767° N | 73.9417° W
8518668 | Horns Hook, East 90th Street, East River, New York, New York (sub) | Sub | 40.7767° N | 73.9417° W
ACT6746_1 | Horse Reach, Charleston Harbor, South Carolina Current | Sub | 32.7862° N | 79.9150° W
9446451 | Horsehead Bay, Carr Inlet, Puget Sound, Washington | Sub | 47.3017° N | 122.6820° W
8724139 | Horseshoe Keys, south end, Florida | Sub | 24.7667° N | 81.2833° W
ACT4951_1 | Horseshoe Point, 1.7 miles east of, Chesapeake Bay, Maryland Current | Sub | 38.8383° N | 76.4533° W
8727648 | Horseshoe Point, Florida | Ref | 29.4367° N | 83.2933° W
9461162 | Hot Springs Bay, Tanaga Island, Alaska | Sub | 51.7783° N | 177.8000° W
PCT2806_1 | Hotspur Island, 0.5 mile southeast of, Felice Strait, Alaska Current | Sub | 54.9667° N | 131.4833° W
ACT8876_2 | Houston Channel, W of Port Bolivar (Depth 14ft), Galveston Bay, Texas Current | Sub | 29.3647° N | 94.7967° W
ACT8876_3 | Houston Channel, W of Port Bolivar (Depth 26ft), Galveston Bay, Texas Current | Sub | 29.3647° N | 94.7967° W
ACT8876_1 | Houston Channel, W of Port Bolivar (Depth 3ft), Galveston Bay, Texas Current | Sub | 29.3647° N | 94.7967° W
ACT8881_2 | Houston Ship Channel (Red Fish Bar) (Depth 14ft), Galveston Bay, Texas Current | Sub | 29.5073° N | 94.8747° W
ACT8881_3 | Houston Ship Channel (Red Fish Bar) (Depth 24ft), Galveston Bay, Texas Current | Sub | 29.5073° N | 94.8747° W
ACT8881_1 | Houston Ship Channel (Red Fish Bar) (Depth 7ft), Galveston Bay, Texas Current | Sub | 29.5073° N | 94.8747° W
8770777 | Houston Ship Channel, Galveston Bay, Manchester, Texas | Ref | 29.7262° N | 95.2658° W
8770777 | Houston Ship Channel, Galveston Bay, Manchester, Texas (sub) | Sub | 29.7262° N | 95.2658° W
8417367 | Howard Point, New Meadows River, Casco Bay, Maine | Sub | 43.8900° N | 69.8833° W
8724257 | Howe Key, northwest end, Florida | Sub | 24.7583° N | 81.4283° W
8724243 | Howe Key, south end, Harbor Channel, Florida | Sub | 24.7250° N | 81.4067° W
8677406 | Howe Street Pier, Brunswick, Georgia | Ref | 31.1446° N | 81.4968° W
ACT5126_1 | Howell Point, 0.4 mile NNW of, Chesapeake Bay, Maryland Current | Sub | 39.3767° N | 76.1150° W
ACT6001_1 | Howell Point, 0.5 n.mi. south of (Depth 7ft), Choptank River, Maryland Current | Sub | 38.6038° N | 76.1145° W
ACT5121_1 | Howell Point, 0.8 n.mi. west of (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 39.3705° N | 76.1300° W
TPT2737 | Howland Island | Sub | 0.8000° N | 176.6333° W
8728757 | Huckleberry Landing, Jackson River, Florida | Ref | 29.7700° N | 85.0850° W
8675245 | Hudson Creek entrance, Georgia | Sub | 31.4467° N | 81.3433° W
8727061 | Hudson, Hudson Creek, Florida | Sub | 28.3617° N | 82.7100° W
8518974 | Hudson, Hudson River, New York | Sub | 42.2500° N | 73.8000° W
8444351 | Hull, Massachusetts | Sub | 42.3033° N | 70.9200° W
9458964 | Hump Island, Kuiukta Bay, Alaska | Ref | 56.1133° N | 158.5980° W
9458964 | Hump Island, Kuiukta Bay, Alaska (sub) | Sub | 56.1133° N | 158.5980° W
9440563 | Hungry Harbor, Washington | Sub | 46.2583° N | 123.8480° W
9450139 | Hunter Bay, Alaska | Sub | 54.8717° N | 132.3220° W
8517673 | Hunters Point, Newtown Creek, East River, New York | Sub | 40.7400° N | 73.9617° W
9414358 | Hunters Point, San Francisco Bay, California | Ref | 37.7300° N | 122.3570° W
9414358 | Hunters Point, San Francisco Bay, California (sub) | Sub | 37.7300° N | 122.3570° W
PCT1216_1 | Hunting Island, south of (Depth 20ft), Washington Current | Sub | 46.2072° N | 123.4042° W
8515921 | Huntington Harbor Lighthouse, Huntington Bay, Long Island, New York | Ref | 40.9100° N | 73.4317° W
8515921 | Huntington Harbor Lighthouse, Huntington Bay, Long Island, New York (sub) | Sub | 40.9100° N | 73.4317° W
8638401 | Huntington Park, James River, Virginia | Sub | 37.0133° N | 76.4583° W
8518621 | Hunts Point, East River, New York | Sub | 40.8000° N | 73.8733° W
ACT3376_1 | Hunts Point, southwest of, East River, New York Current | Sub | 40.8000° N | 73.8833° W
ACT7091_1 | Hutchinson Island, Ashepoo River (Depth 10ft), South Carolina Current | Sub | 32.5317° N | 80.4350° W
8667351 | Hutchinson Island, Ashepoo River, South Carolina | Sub | 32.5517° N | 80.4817° W
8668223 | Hwy. 170 bridge, Broad River, South Carolina | Sub | 32.3867° N | 80.7767° W
8727012 | Hwy. 19 bridge, Pithlachascotee River, Florida | Sub | 28.2683° N | 82.7267° W
8447605 | Hyannis Port, Nantucket Sound, Massachusetts | Ref | 41.6317° N | 70.3000° W
9450364 | Hydaburg, Sukkwan Strait, Alaska | Ref | 55.2017° N | 132.8230° W
8518951 | Hyde Park, Hudson River, New York | Ref | 41.7833° N | 73.9500° W
8762483 | I-10 Bonnet Carre Floodway, Louisiana | Ref | 30.0679° N | 90.3900° W
8720357 | I-295 Bridge (west end), St. Johns River, Florida | Ref | 30.1917° N | 81.6917° W
8720357 | I-295 Bridge (west end), St. Johns River, Florida (sub) | Sub | 30.1917° N | 81.6917° W
8665099 | I-526 bridge, Ashley River, South Carolina | Ref | 32.8367° N | 80.0217° W
8665099 | I-526 bridge, Ashley River, South Carolina (sub) | Sub | 32.8367° N | 80.0217° W
TWC1657 | Ideal Cove, Mitkof Island, Frederick Sound, Alaska | Sub | 56.6667° N | 132.6333° W
TPT2647 | Ifalik Atoll, Caroline Islands, FSM | Sub | 7.2500° N | 144.4500° E
TWC2009 | Iliamna Bay, Cook Inlet, Alaska | Sub | 59.6167° N | 153.5833° W
9440597 | Ilwaco, Baker Bay, Washington | Sub | 46.3033° N | 124.0400° W
9410120 | Imperial Beach, California | Sub | 32.5783° N | 117.1350° W
9462408 | Inanudak Bay, Umnak Island, Alaska | Sub | 53.2967° N | 168.3520° W
8761677 | Independence Island, Barataria Bay, Louisiana | Sub | 29.3100° N | 89.9383° W
8723094 | Indian Creek Golf Club, ICWW, Florida | Sub | 25.8750° N | 80.1433° W
8579381 | Indian Head, Potomac River, Maryland | Sub | 38.6017° N | 77.1850° W
8723851 | Indian Key Anchorage, Lower Matecumbe Key, Florida | Sub | 24.8683° N | 80.7033° W
TEC4183 | Indian Key, Florida | Sub | 25.8000° N | 81.4667° W
8723843 | Indian Key, Hawk Channel, Florida | Sub | 24.8767° N | 80.6767° W
PCT2841_1 | Indian Reef, Felice Strait, Alaska Current | Sub | 55.0333° N | 131.3500° W
8726625 | Indian Rocks Beach (inside), Florida | Sub | 27.8767° N | 82.8500° W
9450212 | Ingraham Bay, Prince of Wales Island, Alaska | Sub | 54.9800° N | 132.0070° W
8535419 | Ingram Thorofare, Townsends Inlet, New Jersey | Ref | 39.1100° N | 74.7383° W
8535419 | Ingram Thorofare, Townsends Inlet, New Jersey (sub) | Sub | 39.1100° N | 74.7383° W
9452629 | Inian Cove, North Inian Pass, Cross Sound, Alaska | Sub | 58.2633° N | 136.3250° W
8558690 | Inlet (Coast Guard Station), Indian River, Delaware | Ref | 38.6100° N | 75.0700° W
8558690 | Inlet (Coast Guard Station), Indian River, Delaware (sub) | Sub | 38.6100° N | 75.0700° W
8639207 | Inside channel, Rudee Inlet, Virginia | Ref | 36.8317° N | 75.9733° W
8639207 | Inside channel, Rudee Inlet, Virginia (sub) | Sub | 36.8317° N | 75.9733° W
9415228 | Inverness, Tomales Bay, California | Sub | 38.1133° N | 122.8680° W
8725418 | Iona Shores, Caloosahatchee River, Florida | Sub | 26.5217° N | 81.9650° W
9415095 | Irish Landing, Sand Mound Slough, San Joaquin River, California | Sub | 38.0333° N | 121.5830° W
9752619 | Isabel Segunda, Vieques Island, Puerto Rico | Ref | 18.1525° N | 65.4438° W
PCT5446_1 | Isanotski Strait (False Pass Cannery), Alaska Current | Ref | 54.8667° N | 163.4000° W
9462961 | Isanotski Strait Entrance, Aleutian Islands, Alaska | Ref | 54.7784° N | 163.3643° W
9752962 | Isla Palominos, Puerto Rico | Ref | 18.3450° N | 65.5695° W
8723808 | Islamorada, Upper Matecumbe Key, Florida Bay, Florida | Sub | 24.9250° N | 80.6317° W
8533345 | Island Beach, Barnegat Bay, New Jersey | Sub | 39.8517° N | 74.0883° W
8533535 | Island Beach, Sedge Islands, Barnegat Bay, New Jersey | Sub | 39.7883° N | 74.0983° W
8414288 | Isle Au Haut, Penobscot Bay, Maine | Sub | 44.0733° N | 68.6367° W
ACT7511_1 | Isle of Hope City, SE of, Skidaway River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 31.9767° N | 81.0467° W
ACT7516_1 | Isle of Hope City, Skidaway River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 31.9800° N | 81.0550° W
TEC3411 | Isle of Hope, Skidaway River, Georgia | Sub | 31.9833° N | 81.0500° W
8665494 | Isle of Palms Pier, South Carolina | Sub | 32.7833° N | 79.7850° W
8416968 | Isle of Springs, Sheepscot River, Maine | Sub | 43.8600° N | 69.6867° W
TWC2023 | Izhut Bay, Alaska | Sub | 58.2167° N | 152.3167° W
8516999 | J.F.K. International Airport, Jamaica Bay, New York | Sub | 40.6233° N | 73.7833° W
8760841 | Jack Bay, Louisiana | Sub | 29.3667° N | 89.3450° W
9454309 | Jack Bay, Valdez Arm, Alaska | Sub | 61.0400° N | 146.6150° W
TEC3023 | Jack Creek entrance, Bulls Bay, South Carolina | Sub | 32.9333° N | 79.5833° W
9454507 | Jackson Cove, Glacier Island, Prince William Sound, Alaska | Sub | 60.8800° N | 147.2230° W
8636735 | Jackson Creek, Deltaville, Piankatank River, Virginia | Sub | 37.5483° N | 76.3317° W
8665737 | Jacksonboro Camp, South Edisto River, South Carolina | Sub | 32.7533° N | 80.4500° W
8720291 | Jacksonville Beach, Florida | Ref | 30.2833° N | 81.3867° W
8720291 | Jacksonville Beach, Florida (sub) | Sub | 30.2833° N | 81.3867° W
8720242 | Jacksonville, Long Branch, Florida | Ref | 30.3600° N | 81.6200° W
8720242 | Jacksonville, Long Branch, Florida (sub) | Sub | 30.3600° N | 81.6200° W
8720215 | Jacksonville, Navy Fuel Depot, Florida | Sub | 30.4000° N | 81.6267° W
ACT8041_1 | Jacksonville, off Washington St, St. Johns River, Florida Current | Sub | 30.3217° N | 81.6533° W
8662237 | Jacobs Wharf, Sampit River, South Carolina | Sub | 33.3633° N | 79.3550° W
8424601 | Jaffrey Point, Portsmouth Harbor, New Hampshire | Sub | 43.0567° N | 70.7133° W
TPT2703 | Jaluit Atoll (SE Pass), Marshall Islands | Sub | 5.9167° N | 169.6500° E
8771721 | Jamaica Beach, West Bay, Galveston Bay, Texas | Sub | 29.2000° N | 94.9850° W
8665775 | James Island Creek, 1 mi. above ent., Ashley River, South Carolina | Sub | 32.7450° N | 79.9483° W
ACT4896_1 | James Island, 2.5 miles WNW of, Chesapeake Bay, Maryland Current | Sub | 38.5333° N | 76.3933° W
ACT4891_1 | James Island, 3.4 miles west of, Chesapeake Bay, Maryland Current | Sub | 38.5250° N | 76.4200° W
9442388 | James Island, Washington | Sub | 47.9067° N | 124.6470° W
8662405 | Jamestown Bridge, Santee River, South Carolina | Sub | 33.3050° N | 79.6783° W
8637712 | Jamestown Wharf, Jamestown, Virginia | Ref | 37.2201° N | 76.7914° W
9457634 | Japanese Bay, Kodiak Island, Alaska | Ref | 56.9600° N | 153.6870° W
ACT7081_1 | Jehossee Island, S tip, South Edisto River (Depth 15ft), South Carolina Current | Sub | 32.6033° N | 80.4200° W
ACT7851_1 | Jekyll Creek, south entrance, St. Andrews Sound, Georgia Current | Sub | 31.0350° N | 81.4333° W
8677832 | Jekyll Island Marina, Jekyll Creek, Georgia | Sub | 31.0567° N | 81.4233° W
8667982 | Jenkins Creek, 1 mi. above entrance, Morgan River, South Carolina | Sub | 32.4400° N | 80.5533° W
8668091 | Jenkins Creek, Polawana Island, Morgan River, South Carolina | Sub | 32.4200° N | 80.5767° W
8652226 | Jennettes Pier, Nags Head (ocean), North Carolina | Sub | 35.9100° N | 75.5917° W
8722338 | Jensen Beach, Indian River, Florida | Sub | 27.2350° N | 80.2100° W
8630111 | Jesters Island, Virginia | Ref | 37.9817° N | 75.3017° W
8723873 | Jewfish Hole, Long Key, Florida Bay, Florida | Sub | 24.8383° N | 80.7983° W
9443551 | Jim Creek, Washington | Ref | 48.1872° N | 124.0625° W
ACT8471_1 | Joe Island, 1.8 miles northwest of, Tampa Bay, Florida Current | Sub | 27.6125° N | 82.6250° W
ACT7476_1 | Joe's Cut, Wilmington River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 31.9433° N | 80.9850° W
ACT7001_1 | Johns Island (Depth 12ft), Stono River, South Carolina Current | Sub | 32.7867° N | 80.1067° W
ACT6986_1 | Johns Island Airport, south of (Depth 12ft), Stono River, South Carolina Current | Sub | 32.6833° N | 80.0033° W
ACT6991_1 | Johns Island Bridge (Depth 14ft), Stono River, South Carolina Current | Sub | 32.7533° N | 80.0100° W
8727235 | Johns Island, Chassahowitzka Bay, Florida | Ref | 28.6917° N | 82.6383° W
8727235 | Johns Island, Chassahowitzka Bay, Florida (sub) | Sub | 28.6917° N | 82.6383° W
8666101 | Johns Island, Church Creek, Wadmalaw River, South Carolina | Sub | 32.7067° N | 80.1567° W
8726533 | Johns Pass, Boca Ciega Bay, Florida | Sub | 27.7850° N | 82.7817° W
8668227 | Johnson Creek Bridge, Hunting Island, St. Helena Sound, South Carolina | Sub | 32.3917° N | 80.4383° W
ACT7686_1 | Johnson Creek, midway between ends, Sapelo Sound, Georgia Current | Sub | 31.6267° N | 81.1883° W
8724172 | Johnson Keys, north end, Florida | Sub | 24.7667° N | 81.3233° W
8724153 | Johnson Keys, south end, Florida | Sub | 24.7433° N | 81.3000° W
1619000 | Johnston Atoll, Pacific Ocean | Ref | 16.7383° N | 169.5300° W
PCT5766_1 | Johnston Channel, off Halftide Rock, Alaska Current | Sub | 55.8333° N | 160.7833° W
8724397 | Johnston Key, southwest end, Turkey Basin, Florida | Sub | 24.7100° N | 81.5933° W
9453215 | Johnstone Passage, Yakutat Bay, Alaska | Sub | 59.5817° N | 139.7020° W
9454319 | Johnstone Point, Hinchinbrook Island, Alaska | Sub | 60.4817° N | 146.6100° W
9415379 | Joice Island, Suisun Slough, Suisun Bay, California | Sub | 38.1800° N | 122.0450° W
8677576 | Jointer Island, Jointer Creek, Georgia | Sub | 31.0950° N | 81.5050° W
TEC3497 | Jones Creek entrance, Hampton River, Georgia | Sub | 31.3000° N | 81.3333° W
8516385 | Jones Inlet (Point Lookout), Long Island, New York | Sub | 40.5867° N | 73.5783° W
8416232 | Jones Neck, Medomak River, Maine | Sub | 44.0150° N | 69.3800° W
ACT5901_1 | Jones Point, Alexandria, Potomac River, Virginia Current | Sub | 38.7937° N | 77.0372° W
8638476 | Jordan Point, James River, Virginia | Sub | 37.3133° N | 77.2233° W
8760736 | Joseph Bayou, Mississippi River, Louisiana | Sub | 29.0583° N | 89.2717° W
8720409 | Julington Creek, Florida | Sub | 30.1350° N | 81.6300° W
PCT3921_1 | Juneau Harbor, S of (Depth 25ft), Gastineau Channel, Stephens Passage, Alaska Current | Sub | 58.2912° N | 134.4070° W
9452210 | Juneau, Gastineau Channel, Stephens Pass, Alaska | Ref | 58.2983° N | 134.4120° W
TEC3783 | Jupiter Inlet, U.S. Highway 1 Bridge, Florida | Sub | 26.9483° N | 80.0850° W
8722495 | Jupiter Inlet, south jetty, Florida | Sub | 26.9433° N | 80.0733° W
8722491 | Jupiter Sound, south end, Florida | Sub | 26.9517° N | 80.0800° W
8722499 | Jupiter, Lake Worth Creek, ICWW, Florida | Sub | 26.9350° N | 80.0850° W
9450254 | Kah Shakes Cove, Revillagigedo Channel, Alaska | Sub | 55.0417° N | 130.9800° W
1615680 | Kahului, Kahului Harbor, Hawaii | Ref | 20.8950° N | 156.4767° W
1617846 | Kailua Kona, Hawaii Island, Hawaii | Sub | 19.6433° N | 156.0000° W
9451528 | Kake Harbor, Keku Strait, Alaska | Ref | 56.9483° N | 133.8947° W
9455732 | Kaligan Island (north end), Cook Inlet, Alaska | Ref | 60.5117° N | 151.9520° W
PCT4241_1 | Kalinin Point, 1 mile north of, Salisbury Sound, Alaska Current | Sub | 57.3500° N | 135.8000° W
1613077 | Kamalo Harbor, Molokai Island, Hawaii | Sub | 21.0483° N | 156.8770° W
9461264 | Kanaga Bay, Kanaga Island, Alaska | Sub | 51.7183° N | 177.2000° W
PCT4441_1 | Kanak Island, southeast of, Controller Bay, Alaska Current | Sub | 60.0833° N | 144.3000° W
9449856 | Kanaka Bay, San Juan Island, Haro Strait, Washington | Ref | 48.4850° N | 123.0830° W
9458365 | Kanatak Lagoon, Portage Bay, Alaska | Sub | 57.5200° N | 156.0520° W
9450581 | Kasaan, Kasaan Bay, Alaska | Sub | 55.5350° N | 132.3970° W
TWC2187 | Kashega Bay, Unalaska Island, Alaska | Sub | 53.4667° N | 167.0833° W
9455517 | Kasitsna Bay, Kachemak Bay, Alaska | Ref | 59.4683° N | 151.5650° W
9451717 | Kasnyku Bay, Alaska | Sub | 57.2167° N | 134.8680° W
TWC1513 | Kasook Inlet, Sukkwan Island, Tlevak Strait, Alaska | Sub | 55.0167° N | 132.7833° W
9450176 | Kassa Inlet entrance, Alaska | Sub | 54.9267° N | 132.5220° W
TWC2095 | Katmai Bay, Shelikof Strait, Alaska | Sub | 58.0000° N | 154.9833° W
1614465 | Kaumalapau, Lanai Island, Hawaii | Sub | 20.7900° N | 156.9950° W
1613198 | Kaunakakai Harbor, Molokai Island, Hawaii | Ref | 21.0850° N | 157.0320° W
1613198 | Kaunakakai Harbor, Molokai Island, Hawaii (sub) | Sub | 21.0850° N | 157.0320° W
1617433 | Kawaihae, Hawaii Island, Hawaii | Ref | 20.0366° N | 155.8294° W
1617433 | Kawaihae, Hawaii Island, Hawaii (sub) | Sub | 20.0366° N | 155.8294° W
9448094 | Kayak Point, Washington | Sub | 48.1367° N | 122.3670° W
TWC2025 | Kazakof Bay, Marmot Bay, Alaska | Sub | 58.1333° N | 152.5667° W
8530772 | Kearny Point, Hackensack River, New Jersey | Sub | 40.7283° N | 74.1033° W
8531262 | Keasbey, Raritan River, New Jersey | Ref | 40.5083° N | 74.3117° W
8744284 | Keesler AFB, Back Bay, Biloxi, Mississippi | Ref | 30.4183° N | 88.9250° W
9450281 | Keete Inlet, Alaska | Sub | 55.0800° N | 132.4900° W
9450258 | Keete Island, Nutkwa Inlets, Alaska | Sub | 55.0467° N | 132.5770° W
8725019 | Keewaydin Island (inside), Florida | Ref | 26.0250° N | 81.7683° W
9450988 | Kell Bay, Affleck Canal, Kuiu Island, Alaska | Sub | 56.1500° N | 134.1330° W
9450142 | Kelp Island Passage, Duke Island, Dixon Entrance, Alaska | Sub | 54.8767° N | 131.3000° W
8724292 | Kemp Channel Viaduct, Florida Keys, Florida | Sub | 24.6617° N | 81.4683° W
9455742 | Kenai City Pier, Cook Inlet, Alaska | Sub | 60.5450° N | 151.2180° W
TWC1983 | Kenai River entrance, Cook Inlet, Alaska | Sub | 60.5500° N | 151.2833° W
8593909 | Kenilworth Aquatic Garden, Anacostia River, DC | Sub | 38.9100° N | 76.9550° W
8418911 | Kennebunkport, Kennebunk River, Maine | Ref | 43.3583° N | 70.4767° W
8418911 | Kennebunkport, Kennebunk River, Maine (sub) | Sub | 43.3583° N | 70.4767° W
ACT6131_1 | Kent Island Narrows (highway bridge) (Depth 4ft), Chester River, Maryland Current | Sub | 38.9705° N | 76.2472° W
8572792 | Kent Island Narrows, Chesapeake Bay, Maryland | Sub | 38.9667° N | 76.2433° W
8572467 | Kent Point Marina, Chesapeake Bay, Maryland | Ref | 38.8367° N | 76.3733° W
8572467 | Kent Point Marina, Chesapeake Bay, Maryland (sub) | Sub | 38.8367° N | 76.3733° W
ACT4946_1 | Kent Point, 1.3 miles south of, Chesapeake Bay, Maryland Current | Sub | 38.8167° N | 76.3642° W
ACT6051_1 | Kent Point, 1.4 n.mi. east of (Depth 15ft), Eastern Bay, Maryland Current | Sub | 38.8388° N | 76.3375° W
ACT4941_1 | Kent Point, 4 miles southwest of, Chesapeake Bay, Maryland Current | Sub | 38.7917° N | 76.4333° W
ACT4881_1 | Kenwood Beach, 1.5 miles northeast of, Chesapeake Bay, Maryland Current | Sub | 38.5183° N | 76.4817° W
9436031 | Kernville, Siletz River, Oregon | Sub | 44.8967° N | 124.0000° W
9450460 | Ketchikan, Tongass Narrows, Alaska | Ref | 55.3318° N | 131.6262° W
PCT2786_1 | Ketchikan, Tongass Narrows, Alaska Current | Sub | 55.3362° N | 131.6442° W
8532835 | Kettle Creek, Green Island, Barnegat Bay, New Jersey | Sub | 40.0133° N | 74.1133° W
8723232 | Key Biscayne Yacht Club, Biscayne Bay, Florida | Sub | 25.6983° N | 80.1700° W
8723962 | Key Colony Beach, Florida | Ref | 24.7183° N | 81.0167° W
8723962 | Key Colony Beach, Florida (sub) | Sub | 24.7183° N | 81.0167° W
8724517 | Key Haven - Stock Island Channel, Florida | Sub | 24.5800° N | 81.7383° W
8723667 | Key Largo, South Sound, Key Largo, Florida | Sub | 25.1133° N | 80.4167° W
8724293 | Key Lois, southeast end, Florida | Sub | 24.6067° N | 81.4700° W
8724580 | Key West, Florida | Ref | 24.5558° N | 81.8078° W
8724557 | Key West, south side, White Street Pier, Florida | Sub | 24.5450° N | 81.7833° W
8570255 | Keydash, Isle of Wight Bay, Maryland | Sub | 38.3417° N | 75.0850° W
8531545 | Keyport, New Jersey | Sub | 40.4400° N | 74.1983° W
8660831 | Keysfield, Waccamaw River, South Carolina | Sub | 33.7450° N | 79.0650° W
8667062 | Kiawah River Bridge, South Carolina | Sub | 32.6033° N | 80.1317° W
8455137 | Kickamuit River, Narragansett Bay, Rhode Island | Ref | 41.7078° N | 71.2417° W
9462398 | Kigul Island, Umnak Island, Alaska | Sub | 53.0450° N | 168.4420° W
TPT2797 | Kihei, Maalaea Bay, Maui Island, Hawaii | Sub | 20.7833° N | 156.4667° W
8672696 | Kilkenny Club, Kilkenny Creek, Georgia | Sub | 31.7883° N | 81.2033° W
9451895 | Killisnoo, Alaska | Sub | 57.4700° N | 134.5650° W
9452583 | Kimshan Cove, Ogden Passage, Chichagof Island, Alaska | Sub | 57.6867° N | 136.1070° W
9465953 | Kinak Bay, Alaska | Ref | 59.9475° N | 164.2107° W
9459881 | King Cove, Deer Passage, Alaska | Ref | 55.0599° N | 162.3261° W
9410738 | King Harbor, Santa Monica Bay, California | Sub | 33.8467° N | 118.3980° W
ACT7426_1 | King Island, west of, Savannah River, Georgia Current | Sub | 32.1233° N | 81.1350° W
9465149 | King Salmon Airport, Naknek River, Alaska | Sub | 58.6717° N | 156.6570° W
8593545 | Kingman Lake, Anacostia River, DC | Sub | 38.8950° N | 76.9683° W
8679511 | Kings Bay, Navy Base, Georgia | Ref | 30.7967° N | 81.5150° W
8679511 | Kings Bay, Navy Base, Georgia (sub) | Sub | 30.7967° N | 81.5150° W
9454887 | Kings Bay, Port Nellie Juan, Prince William Sound, Alaska | Sub | 60.5417° N | 148.4600° W
8720001 | Kings Ferry, St. Marys River, Florida | Sub | 30.7867° N | 81.8400° W
ACT7416_1 | Kings Island Channel, Savannah River (Depth 10ft), Savannah River, Georgia Current | Sub | 32.1267° N | 81.1367° W
8516945 | Kings Point, Long Island Sound, New York | Ref | 40.8103° N | 73.7650° W
8517756 | Kingsborough Community College, Sheepshead Bay, Long Island, New York | Ref | 40.5812° N | 73.9338° W
8720058 | Kingsley Creek, RR. bridge, Florida | Sub | 30.6317° N | 81.4767° W
PCT4076_1 | Kingsmill Point Light, 3 miles west of, Chatham Strait, Alaska Current | Sub | 56.8333° N | 134.5167° W
8638424 | Kingsmill, James River, Virginia | Ref | 37.2200° N | 76.6633° W
8638424 | Kingsmill, James River, Virginia (sub) | Sub | 37.2200° N | 76.6633° W
9445639 | Kingston, Appletree Cove, Puget Sound, Washington | Sub | 47.7967° N | 122.4930° W
8518993 | Kingston, Hudson River, New York | Sub | 41.9183° N | 73.9833° W
8635671 | Kinsale, Yeocomico River, Virginia | Sub | 38.0317° N | 76.5767° W
8632200 | Kiptopeke Beach, Chesapeake Bay, Virginia | Ref | 37.1652° N | 75.9884° W
8632200 | Kiptopeke Beach, Chesapeake Bay, Virginia (sub) | Sub | 37.1652° N | 75.9884° W
9413651 | Kirby Park, Elkhorn Slough, Monterey Bay, Port San Luis, California | Ref | 36.8413° N | 121.7453° W
TWC2307 | Kiska Harbor, Kiska Island, Rat Islands, Alaska | Sub | 51.9833° N | 177.5500° E
9462606 | Kisselen Bay, Beaver Inlet, Unalaska Island, Alaska | Sub | 53.7133° N | 166.5720° W
8419807 | Kittery Point, Portsmouth Harbor, New Hampshire | Sub | 43.0817° N | 70.7033° W
8651605 | Kitty Hawk (ocean), North Carolina | Sub | 36.1017° N | 75.7100° W
9491253 | Kivalina, Alaska | Ref | 67.7267° N | 164.5920° W
9457401 | Kizhuyak Bay, Alaska | Sub | 57.8200° N | 152.9000° W
TWC2031 | Kizhuyak Point, Alaska | Sub | 57.9000° N | 152.6500° W
9451858 | Klokachef Island, Alaska | Sub | 57.4167° N | 135.8900° W
9440171 | Knapp Landing, Columbia River, Washington | Ref | 45.7417° N | 122.7550° W
9439069 | Knappa, Knappa Slough, Oregon | Sub | 46.1867° N | 123.5880° W
8724008 | Knight Key Channel, Knight Key, Florida Bay, Florida | Sub | 24.7067° N | 81.1250° W
8724302 | Knockemdown Key, north end, Florida | Sub | 24.7150° N | 81.4783° W
9457261 | Kodiak, Port of Kodiak, Alaska | Sub | 57.7833° N | 152.4280° W
9457283 | Kodiak, St. Paul Harbor, Alaska | Sub | 57.7450° N | 152.4830° W
9457292 | Kodiak, Women's Bay, Alaska | Ref | 57.7303° N | 152.5139° W
1613226 | Kolo, Molokai Island, Hawaii | Sub | 21.0933° N | 157.1970° W
9415229 | Korths Harbor, San Joaquin River, California | Ref | 38.0976° N | 121.5684° W
9490424 | Kotzebue, Kotzebue Sound, Alaska | Ref | 66.9017° N | 162.5820° W
1616696 | Kuheia Bay, Kahoolawe Island, Hawaii | Sub | 20.5950° N | 156.6070° W
9450913 | Kuiu Island, Affleck Canal, Alaska | Sub | 56.0369° N | 134.1150° W
9458819 | Kujulik Bay (North Shore), Alaska | Sub | 56.6133° N | 157.9830° W
9456835 | Kukak, Kukak Bay, Alaska | Sub | 58.3417° N | 154.1170° W
9462557 | Kuliliak Bay, Unalaska Island, Alaska | Sub | 53.4617° N | 167.0200° W
9465265 | Kulukak Point, Alaska | Ref | 58.8400° N | 159.6470° W
9459145 | Kupreanof Harbor, Paul Island, Alaska | Sub | 55.7900° N | 159.3500° W
PCT5776_1 | Kvichak Bay (off Naknek River entrance), Alaska Current | Ref | 58.7000° N | 157.2500° W
9465342 | Kvichak, Kvichak River, Alaska | Sub | 58.9700° N | 156.9470° W
TPT2697 | Kwajalein Atoll (Namur Island), Marshall Islands | Sub | 9.4000° N | 167.4833° E
1820000 | Kwajalein, Marshall Islands | Ref | 8.7317° N | 167.7361° E
ACT1816_1 | L'Hommedieu Shoal, north of west end, Nantucket Sound, Massachusetts Current | Sub | 41.5267° N | 70.5767° W
9448558 | La Conner, Swinomish Channel, Washington | Sub | 48.3917° N | 122.4970° W
9410230 | La Jolla (Scripps Institution Wharf), California | Ref | 32.8669° N | 117.2571° W
9410230 | La Jolla (Scripps Institution Wharf), California (sub) | Sub | 32.8669° N | 117.2571° W
9442396 | La Push, Quillayute River, Washington | Ref | 47.9133° N | 124.6369° W
9442396 | La Push, Quillayute River, Washington (sub) | Sub | 47.9133° N | 124.6369° W
8638671 | Lafayette River, Virginia | Ref | 36.8842° N | 76.2759° W
ACT6571_1 | Lafayette swing bridge, Waccamaw River, Winyah Bay, South Carolina Current | Sub | 33.3687° N | 79.2520° W
8761899 | Lafitte, Barataria Waterway, Louisiana | Ref | 29.6667° N | 90.1117° W
TPT2799 | Lahaina, Maui Island, Hawaii | Sub | 20.8833° N | 156.6833° W
TPT2779 | Laie Bay, Oahu Island, Hawaii | Sub | 21.6500° N | 157.9333° W
8729045 | Laird Bayou, East Bay, St. Andrew Bay, Florida | Sub | 30.1217° N | 85.5283° W
9450904 | Lake Bay, Alaska | Sub | 56.0233° N | 132.9200° W
8767816 | Lake Charles, Calcasieu River, Louisiana | Ref | 30.2236° N | 93.2217° W
8720216 | Lake Forest, Ribault River, Trout River, Florida | Sub | 30.3983° N | 81.6983° W
8510448 | Lake Montauk, Long Island, New York | Ref | 41.0733° N | 71.9350° W
8510448 | Lake Montauk, Long Island, New York (sub) | Sub | 41.0733° N | 71.9350° W
8639219 | Lake Rudee, south end, Virginia | Sub | 36.8250° N | 75.9817° W
8722512 | Lake Worth Creek, Day Beacon 19, ICWW, Florida | Sub | 26.9117° N | 80.0800° W
8722669 | Lake Worth ICW, Florida | Ref | 26.6133° N | 80.0467° W
8722670 | Lake Worth Pier, Florida | Ref | 26.6128° N | 80.0342° W
8722670 | Lake Worth Pier, Florida (sub) | Sub | 26.6128° N | 80.0342° W
8722802 | Lake Wyman, ICWW, Florida | Ref | 26.3700° N | 80.0700° W
8722802 | Lake Wyman, ICWW, Florida (sub) | Sub | 26.3700° N | 80.0700° W
9415423 | Lakeville, Petaluma River, California | Ref | 38.1983° N | 122.5470° W
TWC0649 | Lakeville, Petaluma River, San Pablo Bay, California | Sub | 38.2000° N | 122.5667° W
9751381 | Lameshur Bay, St. John, Virgin Islands | Ref | 18.3182° N | 64.7242° W
8728412 | Lanark, St. George Sound, Florida | Ref | 29.8783° N | 84.5950° W
9450373 | Lancaster Cove, Cholmondeley Sound, Alaska | Sub | 55.2133° N | 132.0950° W
9454296 | Landlocked Bay, Port Fidalgo, Prince William Sound, Alaska | Sub | 60.8533° N | 146.5350° W
8745555 | Landon, Mississippi | Ref | 30.4317° N | 89.0817° W
8638445 | Lanexa, Chickahominy River, Virginia | Ref | 37.4033° N | 76.9117° W
8743838 | Langley Point, Mississippi | Ref | 30.4250° N | 88.8700° W
ACT8936_1 | Largo Shoals, west of, Puerto Rico Current | Sub | 18.3167° N | 65.5833° W
8723651 | Largo Sound, Key Largo, Florida | Sub | 25.1400° N | 80.3950° W
9457724 | Larsen Bay, Kodiak Island, Alaska | Ref | 57.5333° N | 153.9900° W
9755679 | Las Mareas, Puerto Rico | Ref | 17.9283° N | 66.1583° W
9461132 | Lash Bay, Tanaga Island, Alaska | Sub | 51.6717° N | 178.0450° W
9461411 | Laska Cove, Kagalaska Island, Aleutian Islands, Alaska | Sub | 51.8250° N | 176.4020° W
9454713 | Latouche, Latouche Island, Prince William Sound, Alaska | Sub | 60.0533° N | 147.9070° W
8722899 | Lauderdale-by-the-Sea, Anglin Fishing Pier, Florida | Ref | 26.1883° N | 80.0933° W
8764227 | Lawma, Amerada Pass, Louisiana | Ref | 29.4496° N | 91.3381° W
1619645 | Laysan Island, Hawaii | Sub | 25.7667° N | 171.7500° W
ACT7456_1 | Lazaretto Creek Entrance, N of, Bull River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 32.0000° N | 80.9283° W
8666775 | Leadenwah Creek, 3 mi. above entrance, North Edisto River, South Carolina | Sub | 32.6367° N | 80.2017° W
9451422 | Leconte Bay, Frederick Sound, Alaska | Ref | 56.7883° N | 132.5020° W
TWC2101 | Lees Cabins, Wide Bay, Alaska | Sub | 57.4333° N | 156.3000° W
8762084 | Leeville, Bayou Lafourche, Louisiana | Ref | 29.2483° N | 90.2117° W
9751309 | Leinster Point, Leinster Bay, St. John, Virgin Islands | Ref | 18.3676° N | 64.7207° W
8554038 | Leipsic, Leipsic River, Delaware Bay, Delaware | Sub | 39.2450° N | 75.5183° W
ACT7266_1 | Lemon Island South, Chechessee River (Depth 10ft), South Carolina Current | Sub | 32.3500° N | 80.8067° W
9459895 | Lenard Harbor, Cold Bay, Alaska | Sub | 55.1183° N | 162.3780° W
8656539 | Lenoxville Point, North Carolina | Sub | 34.7083° N | 76.6200° W
8636653 | Lester Manor, Pamunkey River, Virginia | Ref | 37.5833° N | 76.9900° W
8636653 | Lester Manor, Pamunkey River, Virginia (sub) | Sub | 37.5833° N | 76.9900° W
9465419 | Levelock, Kvichak River, Alaska | Sub | 59.1133° N | 156.8320° W
8557380 | Lewes, Fort Miles, Delaware | Ref | 38.7828° N | 75.1192° W
ACT1751_1 | Lewis Bay entrance channel, Nantucket Sound, Massachusetts Current | Sub | 41.6317° N | 70.2733° W
8635750 | Lewisetta, Potomac River, Virginia | Ref | 37.9954° N | 76.4646° W
8635750 | Lewisetta, Potomac River, Virginia (sub) | Sub | 37.9954° N | 76.4646° W
8765568 | Lighthouse Point, Atchafalaya Bay, Louisiana | Sub | 29.5233° N | 92.0433° W
8465692 | Lighthouse Point, New Haven Harbor, Connecticut | Sub | 41.2517° N | 72.9050° W
8723824 | Lignumvitae Key, NE side, Florida Bay, Florida | Sub | 24.9033° N | 80.6950° W
8723825 | Lignumvitae Key, west side, Florida Bay, Florida | Sub | 24.9000° N | 80.7050° W
TPT2713 | Likiep Atoll, Marshall Islands | Sub | 9.8167° N | 169.3167° E
9751401 | Lime Tree Bay, St. Croix, Virgin Islands | Ref | 17.6947° N | 64.7538° W
8665475 | Limehouse Bridge, Stono River, South Carolina | Sub | 32.7867° N | 80.1050° W
9452336 | Lincoln Island, Lynn Canal, Alaska | Sub | 58.4983° N | 134.9650° W
PCT3036_1 | Lincoln Rock Light, 1 mile west from, Clarence Strait, Alaska Current | Sub | 56.0500° N | 132.7167° W
9450625 | Lindeman Cove, Kasaan Bay, Alaska | Ref | 55.6017° N | 132.5120° W
9450625 | Lindeman Cove, Kasaan Bay, Alaska (sub) | Sub | 55.6017° N | 132.5120° W
PCT4316_1 | Lindenberg Head, Peril Strait, Alaska Current | Sub | 57.4500° N | 135.0333° W
TWC1785 | Lindenburg Head, Alaska | Sub | 57.4500° N | 135.0333° W
PCT2731_1 | Lion Point, Portland Canal, Alaska Current | Sub | 55.8833° N | 130.0333° W
8661867 | Litchfield Beach bridge, South Carolina | Sub | 33.4717° N | 79.1017° W
8669415 | Little Back River, Hwy. 17, Back River, Savannah River, South Carolina | Sub | 32.1650° N | 81.1300° W
ACT7281_1 | Little Barnwell I., E of, Whale Branch River (Depth 6ft), South Carolina Current | Sub | 32.5017° N | 80.7867° W
8723813 | Little Basin, Upper Matecumbe Key, Florida Bay, Florida | Sub | 24.9150° N | 80.6400° W
8661119 | Little Bull Creek entrance, Bull Creek, Waccamaw River, South Carolina | Sub | 33.6017° N | 79.1183° W
8723534 | Little Card Sound bridge, Florida | Ref | 25.2883° N | 80.3700° W
8638776 | Little Creek NAB, Chesapeake Bay, Virginia | Sub | 36.9117° N | 76.1750° W
8414424 | Little Deer Isle, Eggemoggin Reach, Maine | Sub | 44.2917° N | 68.6933° W
ACT7551_1 | Little Don Island, east of, Vernon River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 31.8700° N | 81.0733° W
8724093 | Little Duck Key, east end, Hawk Channel, Florida | Sub | 24.6817° N | 81.2283° W
ACT7771_1 | Little Egg Island, northwest of (Depth 12ft), Altamaha Sound, Georgia Current | Sub | 31.3183° N | 81.3050° W
8510884 | Little Gull Island, Long Island, New York | Sub | 41.2067° N | 72.1017° W
8447939 | Little Harbor, Woods Hole, Massachusetts | Sub | 41.5200° N | 70.6650° W
8725283 | Little Hickory Island, Estero Bay, Florida | Sub | 26.3533° N | 81.8550° W
8726436 | Little Manatee River, Florida | Ref | 27.7050° N | 82.4483° W
ACT7776_1 | Little Mud River Range (Depth 9ft), Altamaha Sound, Georgia Current | Sub | 31.3267° N | 81.3183° W
ACT7556_1 | Little Ogeechee River Entrance (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 31.8883° N | 81.0983° W
ACT7556_2 | Little Ogeechee River Entrance (Depth 20ft), Wassaw Sound, Georgia Current | Sub | 31.8883° N | 81.0983° W
ACT7596_1 | Little Ogeechee River Entrance, north of (Depth 6ft), Ossabaw Sound, Georgia Current | Sub | 31.8967° N | 81.0950° W
8724177 | Little Pine Key, north end, Florida | Sub | 24.7500° N | 81.3283° W
8724154 | Little Pine Key, south end, Florida | Sub | 24.7133° N | 81.3033° W
8720274 | Little Pottsburg Creek, Florida | Sub | 30.3100° N | 81.6100° W
8660121 | Little River (town), South Carolina | Sub | 33.8700° N | 78.6083° W
8660098 | Little River Neck, north end, South Carolina | Sub | 33.8700° N | 78.5733° W
ACT8361_1 | Little Sarasota Bay, south end, bridge, Florida Current | Sub | 27.1800° N | 82.4950° W
8534287 | Little Sheepshead Creek, Great Bay, New Jersey | Sub | 39.5217° N | 74.3200° W
8724209 | Little Spanish Key, Spanish Banks, Florida | Sub | 24.7733° N | 81.3683° W
8720006 | Little St. Marys River, St. Marys River, Florida | Sub | 30.7317° N | 81.7267° W
ACT7781_1 | Little St. Simon Island (north) (Depth 11ft), Altamaha Sound, Georgia Current | Sub | 31.3117° N | 81.3533° W
8720194 | Little Talbot Island, ocean, Florida | Sub | 30.4300° N | 81.4050° W
8724223 | Little Torch Key, Pine Channel Bridge, south side, Florida | Sub | 24.6650° N | 81.3867° W
8724224 | Little Torch Key, Pine Channel Bridge, south side, Florida (2) | Sub | 24.6650° N | 81.3867° W
8724232 | Little Torch Key, Torch Channel, Florida | Sub | 24.6650° N | 81.3950° W
ACT7586_1 | Little Wassaw Island, SW of (Depth 10ft), Ossabaw Sound, Georgia Current | Sub | 31.8700° N | 81.0500° W
9452928 | Lituya Bay, 2 miles inside entrance, Alaska | Sub | 58.6167° N | 137.6500° W
8578984 | Liverpool Point, Potomac River, Maryland | Sub | 38.4600° N | 77.2700° W
8667411 | Lobeco, Whale Branch, Coosaw River, South Carolina | Sub | 32.5733° N | 80.7450° W
9447110 | Lockheed Shipyard, Harbor Island, Puget Sound, Washington | Sub | 47.5850° N | 122.3620° W
TEC2869 | Lockwoods Folly Inlet, North Carolina | Sub | 33.9167° N | 78.2333° W
8725745 | Locust Point, Hog Island, Charlotte Harbor, Florida | Ref | 26.9300° N | 82.1367° W
9445088 | Lofall, Washington | Sub | 47.8150° N | 122.6570° W
8720051 | Lofton, Lanceford Creek, Florida | Ref | 30.6433° N | 81.5233° W
8720051 | Lofton, Lanceford Creek, Florida (sub) | Sub | 30.6433° N | 81.5233° W
8724698 | Loggerhead Key, Dry Tortugas, Florida | Ref | 24.6317° N | 82.9200° W
9466328 | Lomavik, Alaska | Ref | 60.5543° N | 162.2971° W
8760424 | Lonesome Bayou (Thomasin), Louisiana | Sub | 29.2283° N | 89.0500° W
9454825 | Long Bay Entrance, Culross Passage, Prince William Sound, Alaska | Sub | 60.6917° N | 148.2630° W
8516663 | Long Beach (Bridgeview Yacht Club), New York | Ref | 40.5963° N | 73.6551° W
8516601 | Long Beach (Inside), Hempstead Bay, New York | Sub | 40.6000° N | 73.6500° W
8577004 | Long Beach, Chesapeake Bay, Maryland | Ref | 38.4650° N | 76.4733° W
8577004 | Long Beach, Chesapeake Bay, Maryland (sub) | Sub | 38.4650° N | 76.4733° W
9410686 | Long Beach, Inner Harbor, California | Sub | 33.7717° N | 118.2100° W
9410680 | Long Beach, Terminal Island, California | Ref | 33.7517° N | 118.2270° W
9410680 | Long Beach, Terminal Island, California (sub) | Sub | 33.7517° N | 118.2270° W
8531991 | Long Branch (fishing pier), New Jersey | Sub | 40.3033° N | 73.9767° W
8531942 | Long Branch Reach, Shrewsbury River, New Jersey | Sub | 40.3250° N | 73.9967° W
8638916 | Long Creek, Lynnhaven Bay, Virginia | Sub | 36.9033° N | 76.0700° W
8466664 | Long Hill, Housatonic River, Connecticut | Sub | 41.2750° N | 73.0883° W
8417941 | Long Island, Casco Bay, Maine | Sub | 43.6900° N | 70.1700° W
ACT7531_1 | Long Island, NNE of, Skidaway River (Depth 6ft), Wassaw Sound, Georgia Current | Sub | 31.9567° N | 81.0600° W
ACT7536_1 | Long Island, south of, Skidaway River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 31.9433° N | 81.0733° W
8723879 | Long Key Bight, Long Key, Florida | Sub | 24.8283° N | 80.8083° W
8723887 | Long Key Lake, Long Key, Florida | Sub | 24.8200° N | 80.8167° W
8726494 | Long Key, 0.5mi N. of Corey Causeway, Boca Ciega Bay, Florida | Sub | 27.7517° N | 82.7533° W
8723899 | Long Key, western end, Florida | Sub | 24.8033° N | 80.8500° W
8468799 | Long Neck Point, Long Island Sound, Connecticut | Ref | 41.0383° N | 73.4800° W
8468799 | Long Neck Point, Long Island Sound, Connecticut (sub) | Sub | 41.0383° N | 73.4800° W
ACT6056_1 | Long Point, 1 mile southeast of, Eastern Bay, Maryland Current | Sub | 38.8433° N | 76.3267° W
8571201 | Long Point, Big Annemessex River, Chesapeake Bay, Maryland | Sub | 38.0567° N | 75.8033° W
8535451 | Long Reach, Ingram Thorofare, Townsends Inlet, New Jersey | Sub | 39.1017° N | 74.7550° W
ACT1716_1 | Long Shoal-Norton Shoal, between, Nantucket Sound, Massachusetts Current | Sub | 41.4083° N | 70.3333° W
ACT8391_1 | Longboat Pass, Sarasota Bay, Florida Current | Sub | 27.4417° N | 82.6900° W
9446638 | Longbranch, Filucy Bay, Puget Sound, Washington | Sub | 47.2100° N | 122.7530° W
8534836 | Longport, Risely Channel, New Jersey | Ref | 39.3083° N | 74.5333° W
8534836 | Longport, Risely Channel, New Jersey (sub) | Sub | 39.3083° N | 74.5333° W
9440422 | Longview, Columbia River, Washington | Ref | 46.1061° N | 122.9542° W
8729816 | Lora Point, Escambia Bay, Pensacola Bay, Florida | Ref | 30.5150° N | 87.1617° W
8729816 | Lora Point, Escambia Bay, Pensacola Bay, Florida (sub) | Sub | 30.5150° N | 87.1617° W
9450624 | Loring, Naha Bay, Alaska | Sub | 55.6017° N | 131.6320° W
9410660 | Los Angeles (outer harbor), California | Ref | 33.7199° N | 118.2729° W
TWC0439 | Los Angeles Harbor, Mormon Island, California | Sub | 33.7500° N | 118.2667° W
TWC0427 | Los Patos (highway bridge), California | Sub | 33.7167° N | 118.0500° W
TPT2663 | Losap Atoll, Chuuk, FSM | Sub | 6.9000° N | 152.7333° E
9469338 | Lost River, Seward Peninsula, Alaska | Ref | 65.3900° N | 167.1450° W
9469338 | Lost River, Seward Peninsula, Alaska (sub) | Sub | 65.3900° N | 167.1450° W
8724842 | Lostmans River entrance, Florida | Sub | 25.5533° N | 81.2133° W
9454642 | Louis Bay, Knight Island, Prince William Sound, Alaska | Sub | 60.4617° N | 147.6720° W
9751467 | Lovango Cay, St. John, Virgin Islands | Ref | 18.3607° N | 64.8035° W
ACT6126_1 | Love Point, 1.6 n.mi. east of (Depth 16ft), Chester River, Maryland Current | Sub | 39.0342° N | 76.2678° W
ACT5011_1 | Love Point, 2.5 miles north of, Chesapeake Bay, Maryland Current | Sub | 39.0797° N | 76.3122° W
8572955 | Love Point, Chester River, Maryland | Ref | 39.0317° N | 76.3017° W
8572955 | Love Point, Chester River, Maryland (sub) | Sub | 39.0317° N | 76.3017° W
8533738 | Loveladies Harbor, Barnegat Bay, New Jersey | Sub | 39.7250° N | 74.1367° W
TEC4343 | Lower Anchorage, Apalachicola Bay, Florida | Sub | 29.6000° N | 85.0500° W
8737373 | Lower Bryant Landing, Tensay River, Alabama | Ref | 30.9783° N | 87.8733° W
8578693 | Lower Cedar Point, Potomac River, Maryland | Sub | 38.3417° N | 76.9767° W
8737182 | Lower Hall Landing, Tensaw River, Alabama | Sub | 30.8183° N | 87.9150° W
8579542 | Lower Marlboro, Patuxent River, Maryland | Ref | 38.6550° N | 76.6833° W
8579542 | Lower Marlboro, Patuxent River, Maryland (sub) | Sub | 38.6550° N | 76.6833° W
8666131 | Lower Toogoodoo Creek, 2 mi. above entrance, North Edisto River, South Carolina | Sub | 32.7033° N | 80.2783° W
8661299 | Lower Topsaw Landing, Great Pee Dee River, South Carolina | Sub | 33.6083° N | 79.1517° W
8667901 | Lucy Point Creek entrance, Morgan River, South Carolina | Sub | 32.4517° N | 80.6100° W
8535221 | Ludlam Bay, west side, Corson Inlet, New Jersey | Sub | 39.1767° N | 74.7100° W
8462764 | Lyme, highway bridge, Connecticut River, Connecticut | Sub | 41.3217° N | 72.3500° W
9445441 | Lynch Cove Dock, Washington | Sub | 47.4183° N | 122.9000° W
ACT6186_1 | Lynch Point, Back River, Maryland Current | Sub | 39.2500° N | 76.4383° W
8770733 | Lynchburg Landing, San Jacinto River, Galveston Bay, Texas | Ref | 29.7649° N | 95.0789° W
8770733 | Lynchburg Landing, San Jacinto River, Galveston Bay, Texas (sub) | Sub | 29.7649° N | 95.0789° W
8729102 | Lynn Haven, North Bay, St. Andrew Bay, Florida | Sub | 30.2550° N | 85.6483° W
8443187 | Lynn, Lynn Harbor, Massachusetts | Ref | 42.4583° N | 70.9433° W
8443187 | Lynn, Lynn Harbor, Massachusetts (sub) | Sub | 42.4583° N | 70.9433° W
ACT5966_1 | Lyons Creek Wharf, Patuxent River, Maryland Current | Sub | 38.7467° N | 76.6850° W
PCT3031_1 | Mabel Island, 3 miles west from, Clarence Strait, Alaska Current | Sub | 55.9167° N | 132.5000° W
9450226 | Mabel Island, Alaska | Sub | 55.0000° N | 132.5920° W
ACT7311_1 | MacKay Creek, south entrance (Depth 10ft), Calibogue Sound, South Carolina Current | Sub | 32.2200° N | 80.7900° W
8411467 | Machiasport, Machias River, Maine | Sub | 44.6983° N | 67.3933° W
ACT7816_1 | Mackay R., 0.5 mi. N of Troup Creek entrance, St. Simons Sound, Georgia Current | Sub | 31.2250° N | 81.4333° W
8676766 | Mackay River (Daymark 239), Georgia | Sub | 31.2100° N | 81.4250° W
8676329 | Mackay River (ICWW), Buttermilk Sound, Georgia | Sub | 31.2850° N | 81.3850° W
8413825 | Mackerel Cove, Swans Island, Blue Hill Bay, Maine | Ref | 44.1700° N | 68.4350° W
8413825 | Mackerel Cove, Swans Island, Blue Hill Bay, Maine (sub) | Sub | 44.1700° N | 68.4350° W
9454674 | Macleod Harbor, Montague Island, Prince William Sound, Alaska | Sub | 59.8900° N | 147.7950° W
ACT3491_1 | Macombs Dam Bridge, Harlem River, New York Current | Sub | 40.8283° N | 73.9350° W
9418865 | Mad River Slough, Arcata Bay, Humboldt Bay, California | Sub | 40.8650° N | 124.1480° W
9451152 | Madan Bay, Clarence Strait, Alaska | Ref | 56.3922° N | 132.1690° W
9451152 | Madan Bay, Clarence Strait, Alaska (sub) | Sub | 56.3922° N | 132.1690° W
8726574 | Madeira Beach Causeway, Boca Ciega Bay, Florida | Sub | 27.8083° N | 82.7950° W
ACT3486_1 | Madison Ave. Bridge, Harlem River, New York Current | Sub | 40.8133° N | 73.9350° W
8464041 | Madison, Connecticut | Sub | 41.2700° N | 72.5900° W
TEC4759 | Magens Bay, St. Thomas, Virgin Islands | Sub | 18.3667° N | 64.9167° W
9450753 | Magnetic Point, Union Bay, Earnest Sound, Alaska | Ref | 55.7883° N | 132.1909° W
8664841 | Magnolia Gardens, Ashley River, South Carolina | Sub | 32.8767° N | 80.0833° W
9759110 | Magueyes Island, Caribbean Sea, Puerto Rico | Ref | 17.9700° N | 67.0464° W
8554399 | Mahon River entrance, Delaware Bay, Delaware | Ref | 39.1850° N | 75.4000° W
8554399 | Mahon River entrance, Delaware Bay, Delaware (sub) | Sub | 39.1850° N | 75.4000° W
1617277 | Mahukona, Hawaii Island, Hawaii | Sub | 20.1867° N | 155.9030° W
TWC0940 | Mailboat Slough, Willapa River, Willapa Bay, Washington | Sub | 46.6883° N | 123.8167° W
8723571 | Main Key, Barnes Sound, Florida | Sub | 25.2400° N | 80.4000° W
8534393 | Main Marsh Thorofare, New Jersey | Sub | 39.4783° N | 74.3833° W
8720226 | Main Street Bridge, St. Johns River, Florida | Ref | 30.3200° N | 81.6583° W
8720226 | Main Street Bridge, St. Johns River, Florida (sub) | Sub | 30.3200° N | 81.6583° W
TPT2721 | Majuro Atoll, Marshall Islands | Sub | 7.1167° N | 171.3667° E
9442861 | Makah Bay, Washington | Sub | 48.2967° N | 124.6720° W
1615202 | Makena, Maui Island, Hawaii | Sub | 20.6567° N | 156.4450° W
TWC2175 | Malga Bay, Unalga Island, Aleutian Islands, Alaska | Sub | 53.9833° N | 166.1667° W
TWC2085 | Malina Bay, Shelikof Strait, Alaska | Sub | 58.1833° N | 152.9500° W
9415112 | Mallard Island Ferry Wharf, Suisun Bay, California | Ref | 38.0433° N | 121.9180° W
9415112 | Mallard Island Ferry Wharf, Suisun Bay, California (sub) | Sub | 38.0433° N | 121.9180° W
TPT2719 | Maloelap Atoll, Marshall Islands | Sub | 8.7167° N | 171.2333° E
8533909 | Manahawkin Creek, Manahawkin Bay, New Jersey | Sub | 39.6667° N | 74.2150° W
8533935 | Manahawkin Drawbridge, Manahawkin Bay, New Jersey | Sub | 39.6533° N | 74.1850° W
8725809 | Manasota, Lemon Bay, Florida | Ref | 27.0117° N | 82.4100° W
8532591 | Manasquan Inlet, USCG Station, New Jersey | Sub | 40.1017° N | 74.0350° W
8723575 | Manatee Creek, Manatee Bay, Barnes Sound, Florida | Sub | 25.2350° N | 80.4300° W
8727989 | Mandalay, Aucilla River, Apalachee Bay, Florida | Sub | 30.1267° N | 83.9750° W
ACT8056_2 | Mandarin Point (Depth 15ft), St. Johns River, Florida Current | Sub | 30.1550° N | 81.6850° W
ACT8056_3 | Mandarin Point (Depth 24ft), St. Johns River, Florida Current | Sub | 30.1550° N | 81.6850° W
ACT8056_1 | Mandarin Point (Depth 6ft), St. Johns River, Florida Current | Sub | 30.1550° N | 81.6850° W
8727333 | Mangrove Pt., Crystal Bay, Florida | Ref | 28.8700° N | 82.7233° W
8727333 | Mangrove Pt., Crystal Bay, Florida (sub) | Sub | 28.8700° N | 82.7233° W
ACT3451_1 | Manhattan Bridge, East of (Depth 15ft), East River, New York Current | Sub | 40.7083° N | 73.9900° W
ACT3431_1 | Manhattan, off 31st Street, East River, New York Current | Sub | 40.7397° N | 73.9695° W
8761732 | Manilla, Barataria Bay, Louisiana | Sub | 29.4267° N | 89.9767° W
8652247 | Manns Harbor, outer coast, North Carolina | Ref | 35.9033° N | 75.7700° W
9412802 | Mansfield Cone, California | Ref | 35.9495° N | 121.4819° W
8532786 | Mantoloking, Barnegat Bay, New Jersey | Sub | 40.0367° N | 74.0533° W
8538438 | Mantua, Mantua Creek, New Jersey | Sub | 39.7950° N | 75.1767° W
TWC1583 | Marble Island, Davidson Inlet, Alaska | Sub | 56.0000° N | 133.4667° W
8724967 | Marco Island, Caxambas Pass, Florida | Ref | 25.9083° N | 81.7283° W
8724991 | Marco, Big Marco River, Florida | Ref | 25.9717° N | 81.7283° W
8540433 | Marcus Hook, Pennsylvania | Ref | 39.8117° N | 75.4094° W
8540433 | Marcus Hook, Pennsylvania (sub) | Sub | 39.8117° N | 75.4094° W
9415218 | Mare Island Naval Shipyard, Carquinez Strait, California | Ref | 38.0700° N | 122.2500° W
9415218 | Mare Island Naval Shipyard, Carquinez Strait, California (sub) | Sub | 38.0700° N | 122.2500° W
8667864 | Marine Corps Air Station, Brickyard Creek, Beaufort River, South Carolina | Sub | 32.4650° N | 80.6917° W
8447385 | Marion, Sippican Harbor, Buzzards Bay, Massachusetts | Sub | 41.7050° N | 70.7617° W
8545120 | Market Street Bridge, Schuylkill River, Pennsylvania | Sub | 39.9550° N | 75.1800° W
9441098 | Markham, Grays Harbor, Washington | Sub | 46.9067° N | 123.9980° W
TWC2021 | Marmot Island, Marmot Strait, Alaska | Sub | 58.2333° N | 151.8667° W
8463827 | Maromas, Connecticut River, Connecticut | Sub | 41.5417° N | 72.5517° W
9444972 | Marrowstone Point, Admiralty Inlet, Washington | Sub | 48.0917° N | 122.6900° W
8579629 | Marshall Hall, Potomac River, Maryland | Sub | 38.6867° N | 77.1017° W
9415339 | Marshall, Tomales Bay, California | Sub | 38.1617° N | 122.8930° W
8761529 | Martello Castle, Lake Borgne, Louisiana | Ref | 29.9450° N | 89.8350° W
8448875 | Martha's Vineyard GPS buoy, Martha's Vineyard, Massachusetts | Ref | 41.3262° N | 70.5903° W
9461693 | Martin Harbor, Korovin Bay, Atka Island, Alaska | Sub | 52.2267° N | 174.2920° W
ACT5996_1 | Martin Point, 0.6 n.mi. west of (Depth 18ft), Choptank River, Maryland Current | Sub | 38.6272° N | 76.1358° W
9415102 | Martinez-Amorco Pier, California | Ref | 38.0346° N | 122.1252° W
ACT5876_1 | Maryland Point, Potomac River, Maryland Current | Sub | 38.3467° N | 77.1967° W
TWC1125 | Marysville, Quilceda Creek, Washington | Sub | 48.0450° N | 122.2117° W
8727274 | Mason Creek, Homosassa Bay, Florida | Ref | 28.7617° N | 82.6383° W
8727274 | Mason Creek, Homosassa Bay, Florida (sub) | Sub | 28.7617° N | 82.6383° W
8635154 | Massaponax Sand & Gravel, Rappahannock River, Virginia | Sub | 38.2550° N | 77.4100° W
8773767 | Matagorda Bay Entrance Channel, Texas | Ref | 28.4269° N | 96.3301° W
8773146 | Matagorda City (TCOON), Texas | Ref | 28.7101° N | 95.9140° W
8725366 | Matanzas Pass (fixed bridge) Estero Island, Florida | Sub | 26.4567° N | 81.9533° W
8572770 | Matapeake, Kent Island, Chesapeake Bay, Maryland | Ref | 38.9567° N | 76.3550° W
8572770 | Matapeake, Kent Island, Chesapeake Bay, Maryland (sub) | Sub | 38.9567° N | 76.3550° W
8531526 | Matawan Creek, Route 35 bridge, New Jersey | Sub | 40.4333° N | 74.2183° W
8723852 | Matecumbe Bight, Lower Matecumbe Key, Fla. Bay, Florida | Sub | 24.8650° N | 80.7167° W
8723862 | Matecumbe Harbor, Lower Matecumbe Key, Fla. Bay, Florida | Sub | 24.8517° N | 80.7400° W
8634892 | Mathias Point, Potomac River, Virginia | Sub | 38.3983° N | 77.0533° W
8414876 | Matinicus Harbor, Wheaton Island, Penobscot Bay, Maine | Sub | 43.8617° N | 68.8817° W
8725506 | Matlacha Pass (bascule bridge), Florida | Sub | 26.6317° N | 82.0683° W
8447531 | Mattapoisett, Mattapoisett Harbor, Buzzards Bay, Massachusetts | Sub | 41.6567° N | 70.8133° W
8512668 | Mattituck Inlet, Long Island Sound, New York | Ref | 41.0150° N | 72.5617° W
8537059 | Mauricetown, Maurice River, New Jersey | Sub | 39.2850° N | 74.9917° W
9759394 | Mayagüez, Puerto Rico | Ref | 18.2189° N | 67.1625° W
9759394 | Mayagüez, Puerto Rico (sub) | Sub | 18.2189° N | 67.1625° W
8722946 | Mayan Lake, Florida | Sub | 26.1000° N | 80.1083° W
8724205 | Mayo Key, Big Spanish Channel, Florida | Sub | 24.7333° N | 81.3617° W
ACT7971_2 | Mayport (Depth 17ft), St. Johns River, Florida Current | Sub | 30.3933° N | 81.4333° W
ACT7971_3 | Mayport (Depth 27ft), St. Johns River, Florida Current | Sub | 30.3933° N | 81.4333° W
ACT7971_1 | Mayport (Depth 7ft), St. Johns River, Florida Current | Sub | 30.3933° N | 81.4333° W
8720220 | Mayport (Ferry Depot), Florida | Ref | 30.3933° N | 81.4317° W
8720224 | Mayport, St. Johns River, Florida | Ref | 30.3950° N | 81.4317° W
8534468 | Mays Landing, Great Egg Harbor River, New Jersey | Ref | 39.4483° N | 74.7283° W
8534468 | Mays Landing, Great Egg Harbor River, New Jersey (sub) | Sub | 39.4483° N | 74.7283° W
8663618 | McClellanville, Jeremy Creek, Bulls Bay, South Carolina | Sub | 33.0783° N | 79.4600° W
8571559 | McCready's Creek, Fishing Bay, Chesapeake Bay, Maryland | Ref | 38.3000° N | 76.0050° W
8571559 | McCready's Creek, Fishing Bay, Chesapeake Bay, Maryland (sub) | Sub | 38.3000° N | 76.0050° W
PCT3246_1 | McFarland Islands, Tlevak Strait, Alaska Current | Sub | 55.0667° N | 132.9500° W
PCT1156_1 | McGowan, SSW of (Depth 14ft), Washington Current | Sub | 46.2395° N | 123.9153° W
PCT3041_1 | McHenry Ledge, 1 mile north of, Ernest Sound, Alaska Current | Sub | 55.8000° N | 132.3000° W
8724996 | McIlvaine Bay, Florida | Ref | 25.9850° N | 81.7017° W
9446583 | McMicken Island, Case Inlet, Puget Sound, Washington | Sub | 47.2467° N | 122.8620° W
ACT7371_1 | McQueen Island Cut (Depth 10ft), Savannah River, Georgia Current | Sub | 32.0650° N | 80.9867° W
9447265 | Meadow Point, Shilshole Bay, Puget Sound, Washington | Sub | 47.6883° N | 122.4030° W
8638486 | Meadowville, James River, Virginia | Sub | 37.3783° N | 77.3233° W
8733839 | Meaher State Park, Mobile Bay, Alabama | Ref | 30.6672° N | 87.9364° W
PCT3281_1 | Meares Island, south of, Meares Passage, Alaska Current | Sub | 55.2578° N | 133.1828° W
ACT7636_1 | Medway River at Marsh Island (Depth 10ft), St. Catherines Sound, Georgia Current | Sub | 31.7433° N | 81.2200° W
ACT7646_1 | Medway River, northwest of Cedar Point (Depth 10ft), Georgia Current | Sub | 31.7145° N | 81.1908° W
9415307 | Meins Landing, Montezuma Slough, Suisun Bay, California | Sub | 38.1367° N | 121.9070° W
9466217 | Mekoryuk, Mekoryuk River Entrance, Alaska | Ref | 60.4167° N | 166.1670° W
PCT3226_1 | Mellen Rock, 1 mile east of, Cordova Bay, Alaska Current | Sub | 55.0333° N | 132.6500° W
8537242 | Menantico Creek entrance, Maurice River, New Jersey | Sub | 39.3433° N | 75.0083° W
8638407 | Menchville, James River, Virginia | Sub | 37.0817° N | 76.5250° W
8761742 | Mendicant Island, Barataria Bay, Louisiana | Ref | 29.3183° N | 89.9800° W
TWC0777 | Mendocino, Mendocino Bay, California | Sub | 39.3000° N | 123.8000° W
9450244 | Menefee Anch., Prince of Wales Island, Alaska | Sub | 55.0267° N | 132.0130° W
8448725 | Menemsha Harbor, Massachusetts | Ref | 41.3544° N | 70.7678° W
TEC4495 | Mermentau River entrance, Louisiana | Sub | 29.7500° N | 93.1000° W
8440369 | Merrimacport, Merrimack River, Massachusetts | Ref | 42.8250° N | 70.9883° W
8440369 | Merrimacport, Merrimack River, Massachusetts (sub) | Sub | 42.8250° N | 70.9883° W
8770539 | Mesquite Point, Sabine Pass, Texas | Ref | 29.7667° N | 93.8950° W
8638051 | Messick Point, Back River, Chesapeake Bay, Virginia | Sub | 37.1083° N | 76.3183° W
9450314 | Metlakatla, Port Chester, Alaska | Ref | 55.1283° N | 131.5670° W
9450314 | Metlakatla, Port Chester, Alaska (sub) | Sub | 55.1283° N | 131.5670° W
8630901 | Metompkin Inlet, Virginia | Sub | 37.6717° N | 75.5950° W
ACT1596_1 | Miacomet Pond, 3.0 miles SSE of, Massachusetts Current | Sub | 41.1900° N | 70.0967° W
8723170 | Miami Beach (city pier), Florida | Ref | 25.7683° N | 80.1317° W
8723170 | Miami Beach (city pier), Florida (sub) | Sub | 25.7683° N | 80.1317° W
TWC0863 | Miami Cove, Tillamook Bay, Oregon | Sub | 45.5500° N | 123.9000° W
8723165 | Miami, Miamarina, Biscayne Bay, Florida | Ref | 25.7783° N | 80.1850° W
8723165 | Miami, Miamarina, Biscayne Bay, Florida (sub) | Sub | 25.7783° N | 80.1850° W
8469057 | Mianus, Connecticut | Ref | 41.0392° N | 73.5920° W
8721994 | Micco, Indian River, Florida | Sub | 27.8733° N | 80.4967° W
8761678 | Michoud Substation, ICWW, Louisiana | Sub | 30.0067° N | 89.9367° W
9465022 | Middle Bluff, Kvichak Bay, Bristol Bay, Alaska | Sub | 58.4533° N | 157.5000° W
8571519 | Middle Hooper Island, Chesapeake Bay, Maryland | Sub | 38.2967° N | 76.2050° W
ACT6406_1 | Middle Marshes, S of (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.6783° N | 76.6138° W
8535101 | Middle Thorofare, Ocean Drive bridge, Corson Inlet, New Jersey | Sub | 39.2150° N | 74.6483° W
8724237 | Middle Torch Key, Torch Ramrod Channel, Florida | Sub | 24.6617° N | 81.4017° W
9454224 | Middleton Island (north end), Alaska | Sub | 59.4617° N | 146.3100° W
8464336 | Middletown, Connecticut River, Connecticut | Sub | 41.5600° N | 72.6450° W
ACT8366_1 | Midnight Pass entrance, Florida Current | Sub | 27.2067° N | 82.5100° W
8661947 | Midway Inlet North, Pawleys Island, South Carolina | Sub | 33.4483° N | 79.1117° W
PCT3866_1 | Midway Island, Stephens Passage, Alaska Current | Sub | 57.8333° N | 133.8333° W
8412581 | Milbridge, Narraguagus River, Maine | Ref | 44.5400° N | 67.8750° W
8412581 | Milbridge, Narraguagus River, Maine (sub) | Sub | 44.5400° N | 67.8750° W
ACT7976_2 | Mile Point, southeast of (Depth 18ft), St. Johns River, Florida Current | Sub | 30.3817° N | 81.4450° W
ACT7976_3 | Mile Point, southeast of (Depth 29ft), St. Johns River, Florida Current | Sub | 30.3817° N | 81.4450° W
ACT7976_1 | Mile Point, southeast of (Depth 7ft), St. Johns River, Florida Current | Sub | 30.3817° N | 81.4450° W
8466442 | Milford Harbor, Connecticut | Sub | 41.2183° N | 73.0550° W
8517519 | Mill Basin, Jamaica Bay, New York | Sub | 40.6083° N | 73.9217° W
8636654 | Mill Creek (Grey Point), Rappahannock River, Virginia | Sub | 37.5833° N | 76.4183° W
8533905 | Mill Creek, 1 n.mi. above entrance, Little Egg Harbor, New Jersey | Sub | 39.6650° N | 74.2317° W
PCT3091_1 | Mill Creek, Alaska Current | Sub | 56.4500° N | 132.2167° W
8417127 | Mill Point, Sasanoa River, Sheepscot River, Maine | Sub | 43.8867° N | 69.7633° W
ACT3391_1 | Mill Rock, northeast of, East River, New York Current | Sub | 40.7817° N | 73.9367° W
ACT3396_1 | Mill Rock, west of, East River, New York Current | Sub | 40.7800° N | 73.9417° W
PCT3291_1 | Millar Rocks, Meares Passage, Alaska Current | Sub | 55.2000° N | 133.2500° W
8636458 | Millenbeck, Corrotoman River, Rappahannock River, Virginia | Sub | 37.6683° N | 76.4867° W
ACT5096_1 | Miller Island, 1.5 miles ENE of (Depth 7ft), Chesapeake Bay, Maryland Current | Sub | 39.2750° N | 76.3317° W
8578551 | Mills Point (south of), Wicomico River, Maryland | Sub | 38.3267° N | 76.8333° W
8550658 | Millside, RR. bridge, Christina River, Delaware | Sub | 39.7250° N | 75.5600° W
8729905 | Millview, Perdido Bay, Florida | Ref | 30.4183° N | 87.3567° W
8537359 | Millville, Maurice River, New Jersey | Sub | 39.3917° N | 75.0417° W
TEC4383 | Milton, Blackwater River, Pensacola Bay, Florida | Sub | 30.6167° N | 87.0333° W
9452633 | Miner Island, Lisianski Strait and Inlet, Alaska | Sub | 58.0100° N | 136.3420° W
PCT2726_1 | Miners Point, Portland Canal, Alaska Current | Sub | 55.7167° N | 130.1500° W
8662796 | Minim Creek ent., ICWW, North Santee Bay, South Carolina | Sub | 33.1950° N | 79.2750° W
9457671 | Mining Camp, Uyak Bay, Alaska | Sub | 57.4600° N | 153.8170° W
8720119 | Mink Creek entrance, Nassau River, Florida | Sub | 30.5367° N | 81.5817° W
9450041 | Minnie Bay, Alaska | Sub | 54.7267° N | 132.3020° W
8556198 | Mispillion River entrance, Delaware Bay, Delaware | Sub | 38.9450° N | 75.3133° W
9410196 | Mission Bay, California | Ref | 32.7937° N | 117.2238° W
8724099 | Missouri Key-Little Duck Key Channel, Florida | Sub | 24.6800° N | 81.2350° W
8724107 | Missouri Key-Ohio Key Channel, west side, Florida | Sub | 24.6733° N | 81.2433° W
TWC2119 | Mist Harbor, Nagai Island, Shumagin Islands, Alaska | Sub | 55.1333° N | 159.8500° W
TWC1741 | Mitchell Bay, Kootznahoo Inlet, Alaska | Sub | 57.5333° N | 134.4000° W
9459016 | Mitrofania Island, Alaska | Ref | 55.8900° N | 158.8200° W
9459016 | Mitrofania Island, Alaska (sub) | Sub | 55.8900° N | 158.8200° W
8726769 | Mobbly Bayou, Florida | Sub | 28.0217° N | 82.6550° W
8737048 | Mobile (Mobile State Docks), Alabama | Ref | 30.7083° N | 88.0433° W
8734635 | Mobile Point (Fort Morgan), Alabama | Sub | 30.2333° N | 88.0200° W
8637199 | Mobjack, East River, Mobjack Bay, Virginia | Sub | 37.3733° N | 76.3467° W
PCT2966_1 | Moira Rock, 2 miles east of, Clarence Strait, Alaska Current | Sub | 55.0833° N | 131.9333° W
1612480 | Moku o Loe, Kaneohe Bay, Oahu Island, Hawaii | Ref | 21.4331° N | 157.7900° W
8724062 | Molasses Key Channel, Molasses Keys, Florida | Sub | 24.6833° N | 81.1917° W
9759938 | Mona Island, Puerto Rico | Ref | 18.0899° N | 67.9385° W
8720217 | Moncrief Creek entrance, Trout River, Florida | Sub | 30.3917° N | 81.6617° W
8537052 | Money Island, Nantuxent Creek entrance, Delaware Bay, New Jersey | Sub | 39.2850° N | 75.2383° W
8724082 | Money Key, Florida | Sub | 24.6833° N | 81.2167° W
8639348 | Money Point, South Bridge, Elizabeth River, Virginia | Ref | 36.7783° N | 76.3017° W
8639348 | Money Point, South Bridge, Elizabeth River, Virginia (sub) | Sub | 36.7783° N | 76.3017° W
8416092 | Monhegan Island, Maine | Sub | 43.7650° N | 69.3217° W
ACT1646_1 | Monomoy Point, 6 miles west of, Nantucket Sound, Massachusetts Current | Sub | 41.5583° N | 70.1500° W
ACT1626_1 | Monomoy Pt., channel 0.2 mile west of, Nantucket Sound, Massachusetts Current | Sub | 41.5500° N | 70.0217° W
9454616 | Montague Island, Alaska | Ref | 60.0250° N | 147.5920° W
9454616 | Montague Island, Alaska (sub) | Sub | 60.0250° N | 147.5920° W
8510502 | Montauk Harbor entrance, Long Island, New York | Sub | 41.0750° N | 71.9367° W
8510321 | Montauk Point Light, Long Island Sound, New York | Ref | 41.0717° N | 71.8567° W
8510560 | Montauk, Fort Pond Bay, Long Island Sound, New York | Ref | 41.0483° N | 71.9594° W
9451247 | Monte Carlo Island, Keku Strait, Alaska | Ref | 56.5350° N | 133.7670° W
9451247 | Monte Carlo Island, Keku Strait, Alaska (sub) | Sub | 56.5350° N | 133.7670° W
9413450 | Monterey, Monterey Harbor, California | Ref | 36.6050° N | 121.8881° W
TWC0959 | Montesano, Chehalis River, Grays Harbor, Washington | Sub | 46.9683° N | 123.6000° W
9415402 | Montezuma Slough Bridge, Suisun Bay, California | Sub | 38.1867° N | 121.9800° W
9415205 | Montezuma Slough, Suisun Bay, California | Sub | 38.0767° N | 121.8850° W
ACT7561_1 | Montgomery, Vernon River (Depth 6ft), Wassaw Sound, Georgia Current | Sub | 31.9350° N | 81.1283° W
8447355 | Monument Beach, Buzzards Bay, Massachusetts | Sub | 41.7150° N | 70.6167° W
8444312 | Moon Head, Boston Harbor, Massachusetts | Sub | 42.3083° N | 70.9917° W
8664442 | Moores Landing, ICWW, Sewee Bay, South Carolina | Sub | 32.9367° N | 79.6550° W
9450483 | Mop Point, Thorne Arm, Revillagigedo Channel, Alaska | Sub | 55.3833° N | 131.2350° W
PCT5781_1 | Morakas Point, Naknek River, Kvichak Bay, Alaska Current | Sub | 58.7333° N | 156.9333° W
8656502 | Morehead City Harbor, North Carolina | Sub | 34.7200° N | 76.7108° W
8656496 | Morehead City, North Carolina | Sub | 34.7183° N | 76.6950° W
ACT6366_1 | Morehead City, RR. bridge, N of (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.7228° N | 76.6938° W
ACT6361_1 | Morehead City, S of (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.7167° N | 76.7328° W
8669369 | Moreland Cemetery, May River, South Carolina | Sub | 32.1750° N | 80.8917° W
ACT6866_1 | Moreland, 0.5 n.mi. below, Cooper River, Charleston Harbor, South Carolina Current | Sub | 33.0005° N | 79.9047° W
ACT7116_1 | Morgan Island, NE of, Coosaw River (Depth 15ft), South Carolina Current | Sub | 32.4883° N | 80.4733° W
ACT7146_1 | Morgan Island, North end, Coosaw River (Depth 15ft), South Carolina Current | Sub | 32.5033° N | 80.5367° W
ACT8886_2 | Morgans Point (Depth 15ft), Galveston Bay, Texas Current | Sub | 29.6798° N | 94.9817° W
ACT8886_3 | Morgans Point (Depth 25ft), Galveston Bay, Texas Current | Sub | 29.6798° N | 94.9817° W
ACT8886_1 | Morgans Point (Depth 6ft), Galveston Bay, Texas Current | Sub | 29.6798° N | 94.9817° W
8513388 | Moriches Coast Guard Station, Long Island, New York | Ref | 40.7867° N | 72.7500° W
8513398 | Moriches Inlet, Long Island, New York | Ref | 40.7644° N | 72.7560° W
PCT4331_1 | Morris Reef, south of, Peril Strait, Alaska Current | Sub | 57.4500° N | 134.8167° W
9450172 | Morse Cove, Duke Island, Revillagigedo Channel, Alaska | Sub | 54.9200° N | 131.2550° W
9457773 | Moser Bay (Trap Point), Alaska | Sub | 57.0017° N | 154.1480° W
8721164 | Mosquito Lagoon, New Smyrna Beach, Florida | Ref | 29.0233° N | 80.9183° W
8516925 | Motts Basin, Jamaica Bay, New York | Sub | 40.6167° N | 73.7583° W
8635409 | Mount Holly, Nomini Creek, Potomac River, Virginia | Sub | 38.0983° N | 76.7350° W
ACT2166_1 | Mount Hope Bridge (Depth 7ft), Narragansett Bay, Rhode Island Current | Sub | 41.6400° N | 71.2583° W
ACT2181_1 | Mount Hope Point, northeast of (Depth 10ft), Narragansett Bay, Rhode Island Current | Sub | 41.6800° N | 71.2117° W
8514421 | Mount Sinai Harbor, Long Island, New York | Sub | 40.9633° N | 73.0400° W
ACT6121_1 | Mountain Point, Magothy River entrance, Maryland Current | Sub | 39.0578° N | 76.4372° W
8575229 | Mountain Point, Magothy River, Chesapeake Bay, Maryland | Sub | 39.0617° N | 76.4333° W
PCT3786_1 | Mountain Point, Wrangell Narrows, Alaska Current | Sub | 56.7333° N | 132.9500° W
9414519 | Mowry Slough, San Francisco Bay, California | Sub | 37.4933° N | 122.0420° W
8661734 | Mt. Pleasant Plantation, Black River, Great Pee Dee River, South Carolina | Sub | 33.4950° N | 79.4617° W
9452567 | Mud Bay, Goose Island, Icy Strait, Alaska | Sub | 58.2117° N | 136.0350° W
9450282 | Mud Bay, Hetta Inlet, Alaska | Sub | 55.0817° N | 132.6320° W
8674975 | Mud River, head of (Daymark 156), Georgia | Ref | 31.4867° N | 81.3200° W
8633604 | Muddy Creek Entrance, Chesapeake Bay, Virginia | Sub | 37.8550° N | 75.6750° W
TWC0445 | Mugu Lagoon (ocean pier), California | Sub | 34.1000° N | 119.1000° W
9452584 | Muir Inlet, Glacier Bay, Alaska | Ref | 58.9133° N | 136.1080° W
9452584 | Muir Inlet, Glacier Bay, Alaska (sub) | Sub | 58.9133° N | 136.1080° W
8726364 | Mullet Key Channel (Skyway), Tampa Bay, Florida | Ref | 27.6150° N | 82.7267° W
8726364 | Mullet Key Channel (Skyway), Tampa Bay, Florida (sub) | Sub | 27.6150° N | 82.7267° W
ACT8421_1 | Mullet Key Channel entrance, Tampa Bay, Florida Current | Sub | 27.6045° N | 82.7238° W
ACT8441_1 | Mullet Key Channel, marker '24' (Depth 15ft), Tampa Bay, Florida Current | Sub | 27.6083° N | 82.6940° W
8724238 | Munson Island, Newfound Harbor Channel, Florida | Sub | 24.6233° N | 81.4033° W
8555388 | Murderkill River entrance, Delaware Bay, Delaware | Sub | 39.0583° N | 75.3967° W
TPT2657 | Murilo Atoll, Hall Islands, Chuuk, FSM | Sub | 8.6000° N | 152.2500° E
8416381 | Muscongus Harbor, Muscongus Sound, Maine | Sub | 43.9667° N | 69.4417° W
ACT1706_1 | Muskeget Channel, Nantucket Sound, Massachusetts Current | Sub | 41.3483° N | 70.4200° W
ACT1696_1 | Muskeget I., channel 1 mile northeast of, Nantucket Sound, Massachusetts Current | Sub | 41.3500° N | 70.2850° W
8448817 | Muskeget Island, north side, Nantucket Island, Massachusetts | Sub | 41.3367° N | 70.3050° W
ACT1701_1 | Muskeget Rock, 1.3 miles southwest of, Nantucket Sound, Massachusetts Current | Sub | 41.3200° N | 70.3933° W
8667209 | Musselboro Island, Mosquito Creek, Ashepoo River, South Carolina | Sub | 32.5783° N | 80.4483° W
8725837 | Myakka River, US 41 bridge, Charlotte Harbor, Florida | Ref | 27.0450° N | 82.2933° W
8660401 | Myrtle Beach Airport, South Carolina | Sub | 33.8200° N | 78.7183° W
8660854 | Myrtle Beach, Combination Bridge, South Carolina | Sub | 33.7133° N | 78.9217° W
9444971 | Mystery Bay, Marrowstone Island, Admiralty Inlet, Washington | Sub | 48.0583° N | 122.6920° W
ACT7666_1 | N. Newport River, ESE of S. Newport Cut (Depth 6ft), Georgia Current | Sub | 31.6653° N | 81.2645° W
ACT7651_1 | N. Newport River, NE of Vandyke Creek (Depth 10ft), St. Catherines Sound, Georgia Current | Sub | 31.6912° N | 81.1870° W
ACT7661_1 | N. Newport River, NW of Johnson Creek (Depth 10ft), St. Catherines Sound, Georgia Current | Sub | 31.6630° N | 81.2105° W
ACT7656_1 | N. Newport River, above Walburg Creek (Depth 6ft), St. Catherines Sound, Georgia Current | Sub | 31.6738° N | 81.1953° W
TEC2831 | N.C. State Fisheries, North Carolina | Sub | 34.7167° N | 76.7500° W
9457407 | Nachalni Island, Kupreanof Strait, Alaska | Ref | 57.9783° N | 152.9250° W
8534256 | Nacote Creek, U.S. Highway 9 bridge, Mullica River, New Jersey | Sub | 39.5350° N | 74.4633° W
9753641 | Naguabo, Puerto Rico | Ref | 18.1871° N | 65.7114° W
9440747 | Nahcotta, Willapa Bay, Washington | Ref | 46.5017° N | 124.0230° W
9440747 | Nahcotta, Willapa Bay, Washington (sub) | Sub | 46.5017° N | 124.0230° W
9450104 | Nakat Harbor, Dixon Entrance, Alaska | Sub | 54.8200° N | 130.7000° W
9458779 | Nakchamik Island, Alaska | Sub | 56.3517° N | 157.8120° W
9454563 | Naked Island, McPherson Passage, Prince William Sound, Alaska | Sub | 60.6833° N | 147.3880° W
9465183 | Naknek River entrance, Alaska | Sub | 58.7217° N | 157.0570° W
TPT2665 | Namoluk Atoll, Chuuk, FSM | Sub | 5.9000° N | 153.1333° E
TPT2653 | Namonuito Atoll, Caroline Islands, FSM | Sub | 8.5833° N | 149.6500° E
8450954 | Nannaquaket Neck, Sakonnet River, Rhode Island | Sub | 41.6183° N | 71.2033° W
8444601 | Nantasket Beach, Weir River, Massachusetts | Sub | 42.2700° N | 70.8600° W
ACT1686_1 | Nantucket Harbor entrance channel, Nantucket Sound, Massachusetts Current | Sub | 41.3067° N | 70.1000° W
8449130 | Nantucket, Nantucket Island, Nantucket Island, Massachusetts | Ref | 41.2853° N | 70.0964° W
9415623 | Napa, Napa River, California | Sub | 38.2983° N | 122.2800° W
8725110 | Naples, Gulf Of Mexico, Florida | Ref | 26.1317° N | 81.8075° W
8725114 | Naples, Naples Bay, north end, Florida | Sub | 26.1367° N | 81.7883° W
1618021 | Napoopoo, Kealakekua Bay, Hawaii Island, Hawaii | Sub | 19.4767° N | 155.9220° W
8454658 | Narragansett Pier, Narragansett Bay, Rhode Island | Sub | 41.4217° N | 71.4550° W
PCT3026_1 | Narrow Point, Clarence Strait, Alaska Current | Sub | 55.7833° N | 132.4167° W
PCT2681_1 | Narrows, Pearse Canal, Alaska Current | Sub | 54.8347° N | 130.4855° W
9440662 | Naselle River, 4 miles above swing bridge, Willapa Bay, Washington | Sub | 46.3883° N | 123.8400° W
9440691 | Naselle River, swing bridge, Willapa Bay, Washington | Sub | 46.4300° N | 123.9030° W
8720135 | Nassau River entrance, Florida | Sub | 30.5183° N | 81.4533° W
8720098 | Nassauville, Nassau River East, Florida | Ref | 30.5683° N | 81.5150° W
8720098 | Nassauville, Nassau River East, Florida (sub) | Sub | 30.5683° N | 81.5150° W
9450387 | Natalia Point, Tlevak Strait, Alaska | Sub | 55.2333° N | 133.0430° W
9410152 | National City, San Diego Bay, California | Sub | 32.6650° N | 117.1180° W
PCT0106_1 | National City, San Diego Bay, California Current | Sub | 32.6500° N | 117.1167° W
PCT0111_1 | National City, WSW of Pier 12 (Depth 32ft), San Diego Bay, California Current | Sub | 32.6622° N | 117.1255° W
9447973 | Naval Air Station Whidbey Island, Washington | Ref | 48.3428° N | 122.6858° W
8729678 | Navarre Beach, Florida | Ref | 30.3767° N | 86.8650° W
8729678 | Navarre Beach, Florida (sub) | Sub | 30.3767° N | 86.8650° W
1611400 | Nawiliwili, Nawiliwili Harbor, Kauai Island, Hawaii | Ref | 21.9544° N | 159.3561° W
ACT2246_1 | Nayatt Point, WNW of (Depth 10ft), Narragansett Bay, Rhode Island Current | Sub | 41.7283° N | 71.3600° W
9443090 | Neah Bay, Strait Of Juan De Fuca, Washington | Ref | 48.3703° N | 124.6019° W
8516315 | Neds Creek, Hempstead Bay, New York | Sub | 40.6233° N | 73.5550° W
9437908 | Nehalem, Nehalem River, Oregon | Sub | 45.7100° N | 123.8900° W
9450339 | Nehenta Bay, Gravina Island, Alaska | Sub | 55.1667° N | 131.7970° W
8444488 | Neponset, Neponset River, Boston Harbor, Massachusetts | Sub | 42.2850° N | 71.0400° W
TWC0857 | Nestucca Bay entrance, Oregon | Sub | 45.1667° N | 123.9667° W
9437262 | Netarts, Netarts Bay, Oregon | Sub | 45.4300° N | 123.9450° W
9462948 | Neumans Cove, Bechevin Bay, Aleutian Islands, Alaska | Ref | 54.9667° N | 163.4400° W
8447584 | New Bedford, Buzzards Bay, Massachusetts | Sub | 41.6400° N | 70.9183° W
8532371 | New Bedford, Shark River, New Jersey | Sub | 40.1783° N | 74.0467° W
8531463 | New Brunswick, Raritan River, New Jersey | Ref | 40.4883° N | 74.4350° W
8761927 | New Canal USCG station, Lake Pontchartrain, Louisiana | Ref | 30.0272° N | 90.1133° W
8761927 | New Canal USCG station, Lake Pontchartrain, Louisiana (sub) | Sub | 30.0272° N | 90.1133° W
8551201 | New Castle, Delaware River, Delaware | Sub | 39.6567° N | 75.5617° W
8534104 | New Gretna, Bass River, Mullica River, New Jersey | Sub | 39.5917° N | 74.4417° W
8518939 | New Hamburg, Hudson River, New York | Sub | 41.5833° N | 73.9500° W
8416501 | New Harbor, Muscongus Bay, Maine | Sub | 43.8750° N | 69.4917° W
8465705 | New Haven Harbor, New Haven Reach, Connecticut | Ref | 41.2833° N | 72.9083° W
8465705 | New Haven Harbor, New Haven Reach, Connecticut (sub) | Sub | 41.2833° N | 72.9083° W
9415478 | New Hope Bridge, Mokelumne River, California | Sub | 38.2267° N | 121.4900° W
8461490 | New London, Thames River, Connecticut | Ref | 41.3550° N | 72.0867° W
8530186 | New Millford, Hackensack River, New Jersey | Sub | 40.9350° N | 74.0300° W
ACT8381_1 | New Pass, Sarasota Bay, Florida Current | Sub | 27.3317° N | 82.5817° W
8637590 | New Point (Comfort Shoal), Virginia | Ref | 37.2567° N | 76.2217° W
8637289 | New Point, Virginia | Ref | 37.3467° N | 76.2733° W
8727001 | New Port Richey, Pithlachascotee River, Florida | Sub | 28.2483° N | 82.7233° W
8657167 | New River Inlet, North Carolina | Sub | 34.5333° N | 77.3417° W
8518490 | New Rochelle, New York | Sub | 40.8933° N | 73.7817° W
8512328 | New Suffolk, Peconic Bays, New York | Sub | 40.9917° N | 72.4717° W
ACT7711_1 | New Teakettle Cr., 0.8 mi. N of, Mud River, Sapelo Sound, Georgia Current | Sub | 31.4967° N | 81.2900° W
9414506 | Newark Slough, San Francisco Bay, California | Sub | 37.5133° N | 122.0800° W
8548989 | Newbold, Delaware River, Pennsylvania | Ref | 40.1373° N | 74.7519° W
8548989 | Newbold, Delaware River, Pennsylvania (sub) | Sub | 40.1373° N | 74.7519° W
8518935 | Newburgh, Hudson River, New York | Sub | 41.5000° N | 74.0067° W
8440466 | Newburyport, Merrimack River, Massachusetts | Ref | 42.8150° N | 70.8733° W
8440466 | Newburyport, Merrimack River, Massachusetts (sub) | Sub | 42.8150° N | 70.8733° W
8416608 | Newcastle, Damariscotta River, Maine | Sub | 44.0333° N | 69.5367° W
8726539 | Newman Branch, Tampa Bay, Florida | Ref | 27.7833° N | 82.4067° W
9410580 | Newport Beach, Newport Bay Entrance, Corona del Mar, California | Ref | 33.6033° N | 117.8830° W
9410580 | Newport Beach, Newport Bay Entrance, Corona del Mar, California (sub) | Sub | 33.6033° N | 117.8830° W
8537079 | Newport Landing, Nantuxent Creek, Delaware Bay, New Jersey | Sub | 39.2917° N | 75.1983° W
ACT6376_1 | Newport Marshes, E of (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.7378° N | 76.6805° W
ACT6371_2 | Newport Marshes, SE of (Depth 15ft), Beaufort Inlet, North Carolina Current | Sub | 34.7313° N | 76.6833° W
ACT6371_1 | Newport Marshes, SE of (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.7313° N | 76.6833° W
8638379 | Newport News, James River, Virginia | Sub | 36.9733° N | 76.4333° W
8656306 | Newport River (Yacht Club), North Carolina | Sub | 34.7683° N | 76.6717° W
8452660 | Newport, Narragansett Bay, Rhode Island | Ref | 41.5050° N | 71.3267° W
8461925 | Niantic, Niantic River, Connecticut | Sub | 41.3250° N | 72.1867° W
9450271 | Niblack Anchorage, Moira Sound, Alaska | Sub | 55.0667° N | 132.1200° W
PCT3056_1 | Niblack Islands, Ernest Sound, Alaska Current | Sub | 56.0333° N | 132.0833° W
9455760 | Nikiski, Cook Inlet, Alaska | Ref | 60.6833° N | 151.3980° W
9462450 | Nikolski, Umnak Island, Alaska | Ref | 52.9406° N | 168.8713° W
9455653 | Ninilchik, Cook Inlet, Alaska | Ref | 60.0550° N | 151.6820° W
9451979 | Nismeni Cove, Alaska | Sub | 57.5617° N | 135.4120° W
PCT4291_1 | Nismeni Point, 1 mile north of, Peril Strait, Alaska Current | Sub | 57.5833° N | 135.4167° W
8729962 | Nix Point, Perdido Bay, Florida | Sub | 30.3933° N | 87.4250° W
8660166 | Nixon Crossroads, South Carolina | Sub | 33.8550° N | 78.6483° W
9468216 | Niyrakpak Lagoon entrance, St. Lawrence Island, Alaska | Sub | 63.6200° N | 171.3830° W
PCT3106_1 | No Name Island, near Thoms Place, Zimovia Strait, Alaska Current | Sub | 56.1500° N | 132.1500° W
8724168 | No Name Key, east side, Bahia Honda Channel, Florida | Sub | 24.6983° N | 81.3183° W
ACT1831_1 | Nobska Point, 1 mile southeast of, Vineyard Sound, Massachusetts Current | Sub | 41.5017° N | 70.6433° W
ACT1821_1 | Nobska Point, 1.8 miles east of, Nantucket Sound, Massachusetts Current | Sub | 41.5183° N | 70.6183° W
8449287 | Nomans Land, Martha's Vineyard, Massachusetts | Sub | 41.2617° N | 70.8183° W
9468756 | Nome, Norton Sound, Alaska | Ref | 64.4946° N | 165.4396° W
TPT2655 | Nomwin Atoll, Hall Islands, Chuuk, FSM | Sub | 8.4500° N | 151.7833° E
1610367 | Nonopapa, Niihau Island, Hawaii | Sub | 21.8700° N | 160.2350° W
9456822 | Nordyke Island, Kamishak Bay, Cook Inlet, Alaska | Sub | 59.1783° N | 154.0870° W
8638654 | Norfolk, Elizabeth River, Virginia | Sub | 36.8517° N | 76.2983° W
8726942 | North Anclote Key, Florida | Sub | 28.2100° N | 82.8400° W
9468226 | North Bay, Stuart Island, Norton Sound, Alaska | Sub | 63.6283° N | 162.5170° W
8722208 | North Beach Causeway, Indian River, Florida | Ref | 27.4717° N | 80.3250° W
8533862 | North Beach, Manahawkin Bay, New Jersey | Sub | 39.6750° N | 74.1600° W
8538848 | North Branch, Rancocas Creek, New Jersey | Sub | 39.9983° N | 74.8183° W
8518635 | North Brother Island, East River, New York | Sub | 40.7983° N | 73.8983° W
8725488 | North Captiva Island, Florida | Ref | 26.6050° N | 82.2183° W
8517201 | North Channel Bridge, Grassy Bay, Jamaica Bay, New York | Ref | 40.6450° N | 73.8367° W
ACT6806_1 | North Charleston, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.8637° N | 79.9588° W
8667146 | North Dawson Landing, Coosawhatchie River, Broad River, South Carolina | Sub | 32.5617° N | 80.9100° W
8664992 | North Dewees Island, Capers Inlet, South Carolina | Sub | 32.8500° N | 79.7033° W
ACT7026_1 | North Edisto River entrance, South Carolina Current | Sub | 32.5617° N | 80.1867° W
8450898 | North End, Bay Oil pier, Sakonnet River, Rhode Island | Sub | 41.6517° N | 71.2100° W
9455869 | North Foreland, Alaska | Ref | 61.0433° N | 151.1630° W
8722478 | North Fork, 2 miles above entrance, Loxahatchee River, Florida | Sub | 26.9750° N | 80.1133° W
9437954 | North Fork, Nehalem River, Oregon | Ref | 45.7338° N | 123.8764° W
8722334 | North Fork, St. Lucie River, Florida | Sub | 27.2433° N | 80.3133° W
8724367 | North Harris Channel, Upper Sugarloaf Sound, Florida | Sub | 24.6533° N | 81.5533° W
8414856 | North Haven, Penobscot Bay, Maine | Sub | 44.1267° N | 68.8733° W
8536271 | North Highlands Beach, Delaware Bay, New Jersey | Sub | 39.0183° N | 74.9533° W
PCT0056_1 | North Island (Depth 14ft), San Diego Bay, California Current | Sub | 32.7130° N | 117.2128° W
PCT0056_2 | North Island (Depth 34ft), San Diego Bay, California Current | Sub | 32.7130° N | 117.2128° W
ACT6631_1 | North Jetty, 0.8 mile southeast of, Charleston Harbor, South Carolina Current | Sub | 32.7175° N | 79.8000° W
9437585 | North Jetty, Tillamook Bay, Oregon | Ref | 45.5700° N | 123.9650° W
8723050 | North Miami Beach, Newport Fishing Pier, Florida | Sub | 25.9300° N | 80.1200° W
8660642 | North Myrtle Beach, South Carolina | Sub | 33.7667° N | 78.8150° W
8673499 | North Newport River (Daymark 119), Georgia | Sub | 31.6817° N | 81.1917° W
TEC3445 | North Newport River, Georgia | Sub | 31.6667° N | 81.2667° W
8722557 | North Palm Beach, Lake Worth, Florida | Sub | 26.8267° N | 80.0550° W
8760412 | North Pass, Mississippi River, Louisiana | Sub | 29.2050° N | 89.0367° W
9450366 | North Pass, West End, Tlevak Strait, Alaska | Sub | 55.2050° N | 132.9400° W
ACT5071_1 | North Point, 2.5 miles northeast of (Depth 7ft), Chesapeake Bay, Maryland Current | Sub | 39.2145° N | 76.3953° W
8574857 | North Point, Patapsco River, Maryland | Sub | 39.1967° N | 76.4450° W
9414305 | North Point, Pier 41, San Francisco, San Francisco Bay, California | Ref | 37.8100° N | 122.4130° W
9414305 | North Point, Pier 41, San Francisco, San Francisco Bay, California (sub) | Sub | 37.8100° N | 122.4130° W
8656225 | North River Bridge, North Carolina | Sub | 34.7917° N | 76.6083° W
ACT7756_1 | North River at Darien River (Depth 9ft), Doboy Sound, Georgia Current | Sub | 31.3833° N | 81.3350° W
8662793 | North Santee Bridge, South Carolina | Sub | 33.2100° N | 79.3850° W
TEC2991 | North Santee River Inlet, South Carolina | Sub | 33.1333° N | 79.2500° W
ACT6581_1 | North Santee River entrance (Depth 6ft), South Carolina Current | Sub | 33.1358° N | 79.2408° W
8530531 | North Secaucus, Garretts Reach, Hackensack River, New York | Sub | 40.8050° N | 74.0533° W
8742523 | North Shore, Mississippi | Ref | 30.3733° N | 88.7050° W
9418767 | North Spit, Humboldt Bay, California | Ref | 40.7663° N | 124.2172° W
TEC3409 | North entrance, Wilmington River, Georgia | Sub | 32.0667° N | 81.0000° W
ACT7621_1 | North of Big Tom Creek Entrance (Depth 10ft), Bear River, Georgia Current | Sub | 31.7833° N | 81.1603° W
9462144 | North side, Yunaska Island, Alaska | Sub | 52.6817° N | 170.7070° W
8636558 | Northbury, Pamunkey River, Virginia | Sub | 37.6250° N | 77.1217° W
TWC2069 | Northeast Arm, Uganik Bay, Alaska | Sub | 57.7333° N | 153.3333° W
9468039 | Northeast Cape, St. Lawrence Island, Alaska | Ref | 63.3167° N | 168.9670° W
9450642 | Northern Carroll Inlet GPS Tide Buoy, Alaska | Ref | 55.6290° N | 131.3627° W
8515586 | Northport, Northport Bay, Long Island, New York | Ref | 40.9000° N | 73.3533° W
8515586 | Northport, Northport Bay, Long Island, New York (sub) | Sub | 40.9000° N | 73.3533° W
8512987 | Northville, Long Island, New York | Ref | 40.9817° N | 72.6450° W
8512987 | Northville, Long Island, New York (sub) | Sub | 40.9817° N | 72.6450° W
ACT7631_1 | Northwest of Newell Creek Entrance (Depth 10ft), Bear River, Georgia Current | Sub | 31.7488° N | 81.1655° W
ACT1836_1 | Norton Point, 0.5 mile north of, Vineyard Sound, Massachusetts Current | Sub | 41.4683° N | 70.6650° W
8517811 | Norton Point, Gravesend Bay, New York | Sub | 40.5900° N | 73.9983° W
8516891 | Norton Point, Head of Bay, Jamaica Bay, New York | Ref | 40.6350° N | 73.7467° W
8461392 | Norwich, Thames River, Connecticut | Sub | 41.5233° N | 72.0783° W
8542699 | Norwood City, Darby Creek, Pennsylvania | Sub | 39.8800° N | 75.2900° W
9450711 | Nossuk Bay, Tonowek Bay, Gulf of Esquibel, Alaska | Ref | 55.7217° N | 133.3500° W
9450711 | Nossuk Bay, Tonowek Bay, Gulf of Esquibel, Alaska (sub) | Sub | 55.7217° N | 133.3500° W
ACT6921_1 | Nowell Creek entrance, Wando River, Charleston Harbor, South Carolina Current | Sub | 32.8783° N | 79.8750° W
8664701 | Nowell Creek, Wando River, South Carolina | Sub | 32.9000° N | 79.9000° W
8511779 | Noyack Bay, Shelter Island Sound, New York | Sub | 40.9950° N | 72.3317° W
9417426 | Noyo Harbor, Fort Bragg, California | Ref | 39.4258° N | 123.8051° W
8775244 | Nueces Bay (TCOON), Texas | Ref | 27.8328° N | 97.4859° W
9455308 | Nuka Passage, Alaska | Sub | 59.4083° N | 150.6670° W
9456717 | Nukshak Island, Shelikof Strait, Alaska | Ref | 58.3917° N | 153.9580° W
9456717 | Nukshak Island, Shelikof Strait, Alaska (sub) | Sub | 58.3917° N | 153.9580° W
8535661 | Nummy Island, Grassy Sound Channel, Hereford Inlet, New Jersey | Sub | 39.0283° N | 74.8017° W
9467551 | Nunam Iqua (Sheldon Point), Alaska | Ref | 62.5329° N | 164.8453° W
9414811 | Nurse Slough, Bradmoor Island, Suisun Bay, California | Ref | 38.1833° N | 121.9230° W
9414811 | Nurse Slough, Bradmoor Island, Suisun Bay, California (sub) | Sub | 38.1833° N | 121.9230° W
PCT5801_1 | Nushagak Bay entrance, Alaska Current | Sub | 58.5667° N | 158.4167° W
8444525 | Nut Island, Quincy Bay, Massachusetts | Ref | 42.2800° N | 70.9533° W
8444525 | Nut Island, Quincy Bay, Massachusetts (sub) | Sub | 42.2800° N | 70.9533° W
8724441 | O'Hara Key, north end, Waltz Key Basin, Florida | Sub | 24.6167° N | 81.6450° W
8515336 | Oak Beach, Great South Bay, New York | Sub | 40.6400° N | 73.2950° W
8448208 | Oak Bluffs, Martha's Vineyard, Massachusetts | Sub | 41.4583° N | 70.5550° W
8666282 | Oak Branch, Bohicket Creek, North Edisto River, South Carolina | Sub | 32.6833° N | 80.0967° W
8659182 | Oak Island, Yaupon Beach, North Carolina | Ref | 33.9017° N | 78.0817° W
8659182 | Oak Island, Yaupon Beach, North Carolina (sub) | Sub | 33.9017° N | 78.0817° W
8720305 | Oak Landing, ICWW, Florida | Sub | 30.2533° N | 81.4300° W
9414711 | Oakland Airport, San Francisco Bay, California | Sub | 37.7317° N | 122.2080° W
9414763 | Oakland Berth 67, San Francisco Bay, California | Sub | 37.7950° N | 122.2830° W
9414746 | Oakland Harbor, Park Street Bridge, San Francisco Bay, California | Ref | 37.7717° N | 122.2350° W
9414764 | Oakland Inner Harbor, San Francisco Bay, California | Ref | 37.7950° N | 122.2820° W
9414777 | Oakland Middle Harbor, San Francisco Bay, California | Sub | 37.8050° N | 122.3380° W
9414765 | Oakland Pier, San Francisco Bay, California | Sub | 37.7950° N | 122.3300° W
9414779 | Oakland, Matson Wharf, San Francisco Bay, California | Sub | 37.8100° N | 122.3270° W
8661609 | Oaks Creek, 0.5 mi. above entrance, Murrells Inlet, South Carolina | Sub | 33.5300° N | 79.0433° W
8661684 | Oaks Creek, upper end, Murrells Inlet, South Carolina | Ref | 33.5117° N | 79.0683° W
ACT7491_1 | Oatland Island, north tip (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 32.0733° N | 81.0100° W
8532885 | Ocean Beach, Barnegat Bay, New Jersey | Sub | 39.9883° N | 74.0683° W
9414275 | Ocean Beach, outer coast, California | Sub | 37.7750° N | 122.5130° W
8570282 | Ocean City (Isle of Wight Bay), Maryland | Sub | 38.3317° N | 75.0900° W
8570280 | Ocean City (fishing pier), Maryland | Ref | 38.3267° N | 75.0833° W
8657419 | Ocean City Beach (fishing pier), North Carolina | Sub | 34.4517° N | 77.4950° W
8570283 | Ocean City Inlet, Maryland | Ref | 38.3283° N | 75.0917° W
8570283 | Ocean City Inlet, Maryland (sub) | Sub | 38.3283° N | 75.0917° W
8535375 | Ocean Drive bridge, Townsends Inlet, New Jersey | Ref | 39.1217° N | 74.7167° W
9413616 | Ocean Pier, Moss Landing, Monterey Bay, California | Sub | 36.8017° N | 121.7900° W
8723519 | Ocean Reef Harbor, Key Largo, Florida | Sub | 25.3083° N | 80.2767° W
8722718 | Ocean Ridge, ICWW, Florida | Ref | 26.5267° N | 80.0533° W
8743181 | Ocean Springs Marina, Old Fort Bayou, Mississippi | Ref | 30.4217° N | 88.7883° W
8743281 | Ocean Springs, Mississippi | Ref | 30.3917° N | 88.7983° W
8743495 | Ocean Springs, Old Fort Bayou, Mississippi | Ref | 30.4200° N | 88.8283° W
8531753 | Oceanic Bridge, Navesink River, Shrewsbury River, New Jersey | Sub | 40.3767° N | 74.0150° W
8414249 | Oceanville, Deer Isle, Penobscot Bay, Maine | Ref | 44.1923° N | 68.6209° W
8667281 | Ocella Creek, 2 mi. above entrance, North Edisto River, South Carolina | Sub | 32.5617° N | 80.2383° W
TEC2793 | Ocracoke Inlet, North Carolina | Sub | 35.0667° N | 76.0167° W
8654792 | Ocracoke, Ocracoke Island, North Carolina | Ref | 35.1150° N | 75.9883° W
8654792 | Ocracoke, Ocracoke Island, North Carolina (sub) | Sub | 35.1150° N | 75.9883° W
ACT7566_1 | Odingsell River Entrance (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 31.8683° N | 81.0000° W
ACT7566_2 | Odingsell River Entrance (Depth 20ft), Wassaw Sound, Georgia Current | Sub | 31.8683° N | 81.0000° W
ACT6011_1 | Off Jamaica Point, Choptank River, Maryland Current | Sub | 38.6097° N | 75.9828° W
PCT5886_1 | Off Northeast Cape, St. Lawrence Island, Alaska Current | Sub | 63.3333° N | 168.8333° W
ACT3386_1 | Off Winthrop Ave., Astoria, East River, New York Current | Sub | 40.7867° N | 73.9167° W
9461081 | Ogliuga Island (east coast), Delarof Islands, Alaska | Sub | 51.6033° N | 178.6170° W
8724112 | Ohio Key-Bahia Honda Key Channel, west side, Florida | Sub | 24.6700° N | 81.2517° W
9456463 | Oil Bay, Kamishak Bay, Cook Inlet, Alaska | Sub | 59.6400° N | 153.2620° W
9411406 | Oil Platform Harvest (Topex Project), California | Ref | 34.4692° N | 120.6819° W
9462354 | Okee Bay, Umnak Island, Alaska | Sub | 53.0167° N | 168.8350° W
8531369 | Old Bridge, South River, Raritan River, New Jersey | Ref | 40.4167° N | 74.3633° W
8664878 | Old Capers Landing, Santee Pass, Capers Island, South Carolina | Sub | 32.8700° N | 79.6867° W
8573969 | Old Frenchtown Wharf, Elk River, Maryland | Sub | 39.5750° N | 75.8433° W
9457527 | Old Harbor, Kodiak Island, Alaska | Ref | 57.2028° N | 153.3039° W
8652648 | Old House Channel, North Carolina | Sub | 35.7767° N | 75.5850° W
ACT1591_1 | Old Man Shoal, Nantucket Shoals, Massachusetts Current | Sub | 41.2267° N | 69.9833° W
8418557 | Old Orchard Beach, Maine | Sub | 43.5167° N | 70.3667° W
8632314 | Old Plantation Light, Chesapeake Bay, Virginia | Sub | 37.2333° N | 76.0500° W
8638288 | Old Point Comfort, Hampton Roads, Virginia | Sub | 37.0033° N | 76.3150° W
8663631 | Old Rice Mill, West Branch, Cooper River, South Carolina | Sub | 33.0783° N | 79.9250° W
8675365 | Old Tea Kettle Creek (Daymark 173), Georgia | Sub | 31.4317° N | 81.3067° W
ACT7721_1 | Old Teakettle Creek (north) (Depth 13ft), Sapelo Sound, Georgia Current | Sub | 31.4783° N | 81.3283° W
ACT7741_1 | Old Teakettle Creek (south) (Depth 13ft), Doboy Sound, Georgia Current | Sub | 31.4367° N | 81.3083° W
ACT7736_1 | Old Teakettle Creek Entrance, south of (Depth 15ft), Doboy Sound, Georgia Current | Sub | 31.4200° N | 81.3150° W
8675622 | Old Tower, Sapelo Island, Georgia | Sub | 31.3900° N | 81.2883° W
ACT6221_1 | Old Town Point Wharf, northwest of (Depth 17ft), Elk River, Maryland Current | Sub | 39.5038° N | 75.9187° W
ACT6221_2 | Old Town Point Wharf, northwest of (Depth 29ft), Elk River, Maryland Current | Sub | 39.5038° N | 75.9187° W
8535695 | Old Turtle Thorofare, RR. bridge, Hereford Inlet, New Jersey | Sub | 39.0183° N | 74.8417° W
9457798 | Olga Bay (A. P. A. Cannery), Alaska | Sub | 57.1617° N | 154.2280° W
8760889 | Olga Compressor Station, Grand Bay, Louisiana | Ref | 29.3866° N | 89.3801° W
8760889 | Olga Compressor Station, Grand Bay, Louisiana (sub) | Sub | 29.3866° N | 89.3801° W
9451725 | Olga Point, Olga Strait, Sitka Sound, Alaska | Sub | 57.2283° N | 135.5370° W
9446969 | Olympia, Budd Inlet, Puget Sound, Washington | Sub | 47.0600° N | 122.9030° W
9465174 | Omakstalia Point, Naknek River, Alaska | Sub | 58.7067° N | 156.7570° W
8633214 | Onancock, Onancock Creek, Chesapeake Bay, Virginia | Sub | 37.7117° N | 75.7567° W
ACT7786_1 | Onemile Cut, 1 mile southeast of, Altamaha Sound, Georgia Current | Sub | 31.3133° N | 81.3517° W
TWC2075 | Onion Bay, Kupreanof Strait, Alaska | Sub | 58.0500° N | 153.2333° W
8724863 | Onion Key, Lostmans River, Florida | Sub | 25.6117° N | 81.1333° W
8447277 | Onset Beach, Onset Bay, Buzzards Bay, Massachusetts | Sub | 41.7417° N | 70.6583° W
8770597 | Orange (Old Navy Base), Texas | Ref | 30.0983° N | 93.7217° W
8720374 | Orange Park Landing, Orange Park, Florida | Sub | 30.1683° N | 81.6950° W
TWC1879 | Orca, Orca Inlet, Alaska | Sub | 60.5833° N | 145.7167° W
9449798 | Orcas, Orcas Island, Washington | Sub | 48.6000° N | 122.9500° W
ACT6206_1 | Ordinary Point, 0.4 mile west of, Sassafrass River, Maryland Current | Sub | 39.3742° N | 75.9875° W
ACT6826_1 | Ordnance Reach, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.9063° N | 79.9528° W
8652678 | Oregon Inlet (USCG Station), North Carolina | Ref | 35.7683° N | 75.5267° W
8652659 | Oregon Inlet Bridge, North Carolina | Sub | 35.7733° N | 75.5383° W
8652657 | Oregon Inlet Channel, North Carolina | Sub | 35.7733° N | 75.5583° W
8652587 | Oregon Inlet Marina, Pamlico Sound, North Carolina | Ref | 35.7950° N | 75.5481° W
TEC2771 | Oregon Inlet, North Carolina | Sub | 35.7667° N | 75.5167° W
8511671 | Orient Harbor, Orient, Shelter Island Sound, New York | Ref | 41.1367° N | 72.3067° W
8511671 | Orient Harbor, Orient, Shelter Island Sound, New York (sub) | Sub | 41.1367° N | 72.3067° W
8720954 | Ormond Beach, Halifax River, Florida | Sub | 29.2850° N | 81.0533° W
8720296 | Ortega River entrance, Florida | Sub | 30.2783° N | 81.7050° W
8658501 | Orton Point, Cape Fear River, North Carolina | Sub | 34.0567° N | 77.9400° W
9414868 | Orwood, Old River, San Joaquin River, California | Sub | 37.9383° N | 121.5600° W
8722146 | Oslo, Indian River, Florida | Sub | 27.5933° N | 80.3567° W
8415867 | Otis Cove, St. George River, Maine | Sub | 43.9867° N | 69.2367° W
TWC2311 | Otkriti Bay, Agattu Island, Aleutian Islands, Alaska | Sub | 52.3667° N | 173.6167° E
PCT4286_1 | Otstoia Island Light, 1 mile north of, Peril Strait, Alaska Current | Sub | 57.5833° N | 135.4500° W
8667783 | Otter Island, St. Helena Sound, South Carolina | Sub | 32.4767° N | 80.4200° W
9462465 | Otter Point, Umnak Island, Alaska | Sub | 53.3967° N | 167.8430° W
PCT5441_1 | Otter Point, off of, north side, Unimak Island, Alaska Current | Sub | 55.0667° N | 163.7833° W
9469515 | Outside Lopp Lagoon, Alaska | Ref | 65.7288° N | 168.0321° W
9457287 | Ouzinkie, Spruce Island, Alaska | Ref | 57.9217° N | 152.4980° W
9457287 | Ouzinkie, Spruce Island, Alaska (sub) | Sub | 57.9217° N | 152.4980° W
8728957 | Overstreet, St. Andrew Bay, Florida | Ref | 29.9967° N | 85.3700° W
8572108 | Oxford, Tred Avon River, Maryland | Sub | 38.6933° N | 76.1733° W
8516201 | Oyster Bay Harbor, Oyster Bay, New York | Sub | 40.8667° N | 73.5167° W
8533465 | Oyster Creek, Barnegat Bay, New Jersey | Sub | 39.8083° N | 74.1883° W
8652437 | Oyster Creek, Croatan Sound, North Carolina | Ref | 35.8450° N | 75.6550° W
8631591 | Oyster Harbor, Virginia | Sub | 37.2883° N | 75.9250° W
9414392 | Oyster Point Marina, San Francisco Bay, California | Ref | 37.6650° N | 122.3770° W
9414392 | Oyster Point Marina, San Francisco Bay, California (sub) | Sub | 37.6650° N | 122.3770° W
8727328 | Ozello North, Crystal Bay, Florida | Ref | 28.8633° N | 82.6667° W
8727328 | Ozello North, Crystal Bay, Florida (sub) | Sub | 28.8633° N | 82.6667° W
8727306 | Ozello, St. Martin's River, Florida | Ref | 28.8250° N | 82.6583° W
8727306 | Ozello, St. Martin's River, Florida (sub) | Sub | 28.8250° N | 82.6583° W
8722548 | PGA Boulevard Bridge, Palm Beach, Florida | Ref | 26.8433° N | 80.0667° W
8722548 | PGA Boulevard Bridge, Palm Beach, Florida (sub) | Sub | 26.8433° N | 80.0667° W
ACT7986_1 | Pablo Creek bascule bridge (Depth 3ft), St. Johns River, Florida Current | Sub | 30.3233° N | 81.4383° W
8720232 | Pablo Creek entrance, Florida | Sub | 30.3767° N | 81.4483° W
8720267 | Pablo Creek, ICWW bridge, Florida | Sub | 30.3233° N | 81.4383° W
9413624 | Pacific Mariculture Dock, Monterey Bay, California | Sub | 36.8133° N | 121.7580° W
8775792 | Packery Channel, Texas | Ref | 27.6333° N | 97.2367° W
8721222 | Packwood Place, Florida | Ref | 28.9400° N | 80.8700° W
8779750 | Padre Island, Brazos Santiago Pass, Texas | Ref | 26.0683° N | 97.1567° W
TPT2621 | Pagan Island, Marianas | Sub | 18.1333° N | 145.7667° E
1631428 | Pago Bay, Guam | Ref | 13.4283° N | 144.7969° E
1770000 | Pago Pago, American Samoa | Ref | 14.2767° S | 170.6894° W
8720774 | Palatka, St. Johns River, Florida | Ref | 29.6433° N | 81.6317° W
8720774 | Palatka, St. Johns River, Florida (sub) | Sub | 29.6433° N | 81.6317° W
9440813 | Palix River, south fork, Willapa Bay, Washington | Sub | 46.5867° N | 123.9100° W
8722621 | Palm Beach, Highway 704 bridge, Lake Worth, Florida | Sub | 26.7050° N | 80.0450° W
8722607 | Palm Beach, Lake Worth, Florida | Sub | 26.7333° N | 80.0417° W
8720398 | Palm Valley, ICWW, Florida | Sub | 30.1333° N | 81.3867° W
8670893 | Palmer Johnson Shipyard, Wilmington River, Georgia | Ref | 32.0233° N | 81.0467° W
8720653 | Palmetto Bluff, Florida | Sub | 29.7633° N | 81.5617° W
TPT2739 | Palmyra Island | Sub | 5.8833° N | 162.0833° W
8538853 | Palmyra, Pennsauken Creek, Route 73 bridge, New Jersey | Sub | 39.9933° N | 75.0283° W
9414525 | Palo Alto Yacht Harbor, San Francisco Bay, California | Sub | 37.4583° N | 122.1050° W
8728269 | Panacea, Dickerson Bay, Apalachee Bay, Florida | Sub | 30.0283° N | 84.3867° W
8729210 | Panama City Beach (outside), St. Andrew Bay, Florida | Ref | 30.2133° N | 85.8783° W
8729108 | Panama City, St. Andrew Bay, Florida | Ref | 30.1523° N | 85.6669° W
8729108 | Panama City, St. Andrew Bay, Florida (sub) | Sub | 30.1523° N | 85.6669° W
9451346 | Papke's Landing, Wrangell Narrows, Alaska | Ref | 56.6767° N | 132.9330° W
9451346 | Papke's Landing, Wrangell Narrows, Alaska (sub) | Sub | 56.6767° N | 132.9330° W
9440723 | Paradise Point, Long Island, Willapa Bay, Washington | Sub | 46.4683° N | 123.9450° W
TEC4445 | Paris Road Bridge (ICWW), Louisiana | Sub | 30.0000° N | 89.9333° W
8724353 | Park Channel Bridge, Upper Sugarloaf Sound, Florida | Sub | 24.6550° N | 81.5400° W
8666552 | Park Island, Tom Point Creek, North Edisto River, South Carolina | Sub | 32.6650° N | 80.3167° W
8664782 | Parker Island, Horlbeck Creek, Wando River, South Carolina | Sub | 32.8850° N | 79.8450° W
8534049 | Parker Run, upper end, Little Egg Harbor, New Jersey | Sub | 39.6167° N | 74.3100° W
8729084 | Parker, St. Andrew Bay, Florida | Sub | 30.1267° N | 85.6117° W
ACT7256_1 | Parris Island Lookout Tower, Broad River (Depth 15ft), South Carolina Current | Sub | 32.3117° N | 80.7067° W
ACT7211_1 | Parris Island, Beaufort River (Depth 10ft), Port Royal Sound, South Carolina Current | Sub | 32.3267° N | 80.6567° W
ACT7221_1 | Parris Island, Beaufort River (Depth 15ft), Port Royal Sound, South Carolina Current | Sub | 32.3600° N | 80.6750° W
8668445 | Parris Island, Marine Corps Recruit Depot, Beaufort River, South Carolina | Sub | 32.3500° N | 80.6683° W
ACT7141_1 | Parrot Creek, Coosaw Island (Depth 15ft), South Carolina Current | Sub | 32.4733° N | 80.5450° W
8516501 | Parsonnage Cove, Long Island, New York | Ref | 40.6333° N | 73.6167° W
8741533 | Pascagoula NOAA Lab, Pascagoula River, Mississippi | Ref | 30.3678° N | 88.5631° W
8741196 | Pascagoula Point, Mississippi Sound, Mississippi | Ref | 30.3400° N | 88.5333° W
8741196 | Pascagoula Point, Mississippi Sound, Mississippi (sub) | Sub | 30.3400° N | 88.5333° W
8746819 | Pass Christian Yacht Club, Mississippi Sound, Mississippi | Ref | 30.3100° N | 89.2450° W
8746819 | Pass Christian Yacht Club, Mississippi Sound, Mississippi (sub) | Sub | 30.3100° N | 89.2450° W
TEC4271 | Pass-a-Grille Beach, Boca Ciega Bay, Florida | Sub | 27.6833° N | 82.7333° W
ACT8606_1 | Pass-a-Grille Channel, Florida Current | Sub | 27.6850° N | 82.7350° W
ACT8426_1 | Passage Key Inlet (off Bean Pt.) (Depth 15ft), Tampa Bay, Florida Current | Sub | 27.5393° N | 82.7477° W
8514322 | Patchogue, Patchogue River, Great South Bay, New York | Ref | 40.7500° N | 73.0000° W
8514322 | Patchogue, Patchogue River, Great South Bay, New York (sub) | Sub | 40.7500° N | 73.0000° W
ACT2241_1 | Patience I. and Warwick Neck, between, Narragansett Bay, Rhode Island Current | Sub | 41.6633° N | 71.3733° W
ACT2236_1 | Patience Island, narrows east of, Narragansett Bay, Rhode Island Current | Sub | 41.6583° N | 71.3533° W
9449704 | Patos Island Wharf, Boundary Pass, Washington | Sub | 48.7867° N | 122.9700° W
8721727 | Patrick Air Force Base, Florida | Sub | 28.2450° N | 80.6000° W
9454574 | Patton Bay, Montague Island, Alaska | Sub | 59.9067° N | 147.4500° W
8538512 | Paulsboro, Mantua Creek, New Jersey | Ref | 39.8350° N | 75.2383° W
8538752 | Pavonia, Cooper River, RR. bridge, New Jersey | Sub | 39.9467° N | 75.1050° W
8662006 | Pawleys Island Pier (ocean), South Carolina | Ref | 33.4317° N | 79.1167° W
8453611 | Pawtucket, Seekonk River, Narragansett Bay, Rhode Island | Sub | 41.8683° N | 71.3800° W
8453767 | Pawtuxet, Pawtuxet Cove, Narragansett Bay, Rhode Island | Sub | 41.7617° N | 71.3883° W
8551702 | Pea Patch Island, Bulkhead Shoal Channel, Delaware River, Delaware | Sub | 39.5833° N | 75.5733° W
8418001 | Peak Island, Casco Bay, Maine | Sub | 43.6550° N | 70.2000° W
1612404 | Pearl Harbor, Ford Island Ferry Dock, Oahu Island, Hawaii | Ref | 21.3683° N | 157.9400° W
1612404 | Pearl Harbor, Ford Island Ferry Dock, Oahu Island, Hawaii (sub) | Sub | 21.3683° N | 157.9400° W
8749704 | Pearlington, Pearl River, Mississippi | Sub | 30.2400° N | 89.6150° W
TWC1165 | Peavine Pass, Washington | Sub | 48.6000° N | 122.8000° W
8722404 | Peck Lake, ICWW, Florida | Sub | 27.1133° N | 80.1450° W
8538369 | Pedricktown, Oldmans Creek, Delaware River, New Jersey | Sub | 39.7617° N | 75.4033° W
ACT6566_1 | Pee Dee River, swing bridge, Winyah Bay, South Carolina Current | Sub | 33.3705° N | 79.2638° W
8518949 | Peekskill, Hudson River, New York | Sub | 41.2883° N | 73.9317° W
ACT7101_1 | Pelican Bank, St. Helena Sound (Depth 15ft), South Carolina Current | Sub | 32.4550° N | 80.4283° W
9452611 | Pelican Harbor, Lisianski Inlet, Alaska | Ref | 57.9578° N | 136.2268° W
8762481 | Pelican Islands, Timbalier Bay, Louisiana | Sub | 29.1283° N | 90.4233° W
8416581 | Pemaquid Harbor, Johns Bay, Maine | Sub | 43.8767° N | 69.5250° W
8726651 | Pendola Point, Hillsborough Bay, Florida | Sub | 27.8983° N | 82.4267° W
8448248 | Penikese Island, Buzzards Bay, Massachusetts | Ref | 41.4500° N | 70.9217° W
8448248 | Penikese Island, Buzzards Bay, Massachusetts (sub) | Sub | 41.4500° N | 70.9217° W
8666017 | Penny Creek, south of, Edisto River, South Edisto River, South Carolina | Sub | 32.7150° N | 80.4367° W
8665599 | Pennys Creek, west entrance, Stono River, South Carolina | Sub | 32.7683° N | 80.0700° W
8543925 | Penrose Avenue Bridge, Schuylkill River, Pennsylvania | Sub | 39.8983° N | 75.2117° W
8729840 | Pensacola, Florida | Ref | 30.4044° N | 87.2112° W
8720406 | Peoria Point, Doctors Lake, Florida | Ref | 30.1200° N | 81.7583° W
TEC4301 | Pepperfish Keys, Florida | Sub | 29.5000° N | 83.3667° W
9454561 | Perch Point, Montague Island, Alaska | Ref | 60.1267° N | 147.3950° W
9454561 | Perch Point, Montague Island, Alaska (sub) | Sub | 60.1267° N | 147.3950° W
9457271 | Perenosa Bay, Afognak Island, Alaska | Sub | 58.3567° N | 152.4480° W
8724378 | Perky, Upper Sugarloaf Sound, Florida | Sub | 24.6483° N | 81.5700° W
ACT5861_1 | Persimmon Point, Potomac River, Maryland Current | Sub | 38.3683° N | 76.9900° W
PCT4296_1 | Peschani Point, 1 mile east of, Peril Strait, Alaska Current | Sub | 57.5333° N | 135.3000° W
9415252 | Petaluma River entrance, San Pablo Bay, California | Ref | 38.1153° N | 122.5057° W
9415252 | Petaluma River entrance, San Pablo Bay, California (sub) | Sub | 38.1153° N | 122.5057° W
TWC1867 | Pete Dahl Slough, Copper River Delta, Alaska | Sub | 60.3833° N | 145.4000° W
8667425 | Peters Point, St. Pierre Creek, South Edisto River, South Carolina | Sub | 32.5400° N | 80.3400° W
9451439 | Petersburg, Wrangell Narrows, Alaska | Sub | 56.8150° N | 132.9570° W
9459939 | Peterson Bay, Sanak Islands, Alaska | Sub | 54.3933° N | 162.6370° W
8740405 | Petit Bois Island, Mississippi Sound, Mississippi | Ref | 30.2033° N | 88.4417° W
8410834 | Pettegrove Point, Dochet Island, Maine | Ref | 45.1284° N | 67.1447° W
9758053 | Peñuelas (Punta Guayanilla), Puerto Rico | Ref | 17.9725° N | 66.7618° W
8545240 | Philadelphia (USCG Station), Delaware River, Pennsylvania | Ref | 39.9333° N | 75.1417° W
8545530 | Philadelphia, Municipal Pier 11, Pennsylvania | Ref | 39.9533° N | 75.1383° W
8545530 | Philadelphia, Municipal Pier 11, Pennsylvania (sub) | Sub | 39.9533° N | 75.1383° W
8417087 | Phipps Point, Back River, Maine | Ref | 43.8983° N | 69.7433° W
8417221 | Phippsburg, Kennebec River, Maine | Sub | 43.8183° N | 69.8100° W
8720225 | Phoenix Park, Florida | Ref | 30.3833° N | 81.6367° W
8720225 | Phoenix Park, Florida (sub) | Sub | 30.3833° N | 81.6367° W
9455399 | Picnic Harbor, Rocky Bay, Alaska | Sub | 59.2550° N | 151.4200° W
ACT3441_1 | Pier 67, off 19th Street, East River, New York Current | Sub | 40.7333° N | 73.9667° W
9415266 | Pierce Harbor, Goodyear Slough, Suisun Bay, California | Sub | 38.1267° N | 122.1000° W
8638514 | Pig Point, Nansemond River, Virginia | Sub | 36.9167° N | 76.4350° W
ACT7541_1 | Pigeon Island, SSE of, Skidaway River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 31.9367° N | 81.0767° W
8724033 | Pigeon Key, north side, Florida Bay, Florida | Sub | 24.7050° N | 81.1567° W
8724032 | Pigeon Key, south side, Hawk Channel, Florida | Sub | 24.7033° N | 81.1550° W
9468011 | Pikmiktalik River entrance, Norton Sound, Alaska | Sub | 63.2800° N | 162.6020° W
9414131 | Pillar Point Harbor, Half Moon Bay, California | Ref | 37.5025° N | 122.4822° W
8667591 | Pilot Island, West Branch Boyds Creek, Broad River, South Carolina | Sub | 32.5050° N | 80.8633° W
8760943 | Pilot Station, Southwest Pass, Louisiana | Ref | 28.9250° N | 89.4183° W
8760922 | Pilots Station (east), Southwest Pass, Louisiana | Ref | 28.9322° N | 89.4075° W
8760721 | Pilottown, Louisiana | Ref | 29.1783° N | 89.2583° W
8663539 | Pimlico, West Branch, Cooper River, South Carolina | Sub | 33.0950° N | 79.9533° W
8668944 | Pinckney Island, Mackay Creek, Chechessee River, South Carolina | Sub | 32.2600° N | 80.7667° W
8674512 | Pine Harbor, Sapelo River, Georgia | Sub | 31.5483° N | 81.3717° W
8537488 | Pine Island, Malapartis Creek, Mad Horse Creek, New Jersey | Sub | 39.4217° N | 75.4283° W
8669601 | Pine Island, Ramshorn Creek, Cooper River, South Carolina | Sub | 32.1217° N | 80.8983° W
ACT7061_1 | Pine Island, South Edisto River (Depth 15ft), South Carolina Current | Sub | 32.5067° N | 80.3617° W
ACT8451_1 | Pine Key (Pinellas Bayway bridge), Tampa Bay, Florida Current | Sub | 27.6925° N | 82.7172° W
8667067 | Pine Landing, South Edisto River, South Carolina | Sub | 32.6033° N | 80.3883° W
8418445 | Pine Point, Maine | Ref | 43.5450° N | 70.3333° W
8725528 | Pineland, Pine Island, Florida | Sub | 26.6600° N | 82.1550° W
ACT8516_1 | Piney Point, 0.6 mile NNW of, Tampa Bay, Florida Current | Sub | 27.6537° N | 82.5622° W
8447416 | Piney Point, Buzzards Bay, Massachusetts | Ref | 41.6950° N | 70.7200° W
8447416 | Piney Point, Buzzards Bay, Massachusetts (sub) | Sub | 41.6950° N | 70.7200° W
8720333 | Piney Point, Florida | Sub | 30.2283° N | 81.6633° W
8578240 | Piney Point, Potomac River, Maryland | Sub | 38.1333° N | 76.5333° W
9415056 | Pinole Point, San Pablo Bay, California | Ref | 38.0150° N | 122.3630° W
9459398 | Pirate Cove, Popof Island, Shumagin Islands, Alaska | Sub | 55.3617° N | 160.3600° W
8660475 | Pitch Landing, Waccamaw River, South Carolina | Sub | 33.8000° N | 79.0550° W
9415096 | Pittsburg, New York Slough, Suisun Bay, California | Sub | 38.0367° N | 121.8800° W
8725667 | Placida, Gasparilla Sound, Florida | Sub | 26.8333° N | 82.2650° W
8723769 | Plantation Key, Hawk Channel, Florida | Sub | 24.9733° N | 80.5500° W
9465396 | Platinum, Alaska | Ref | 59.0467° N | 161.8180° W
9465396 | Platinum, Alaska (sub) | Sub | 59.0467° N | 161.8180° W
TEC4735 | Playa Cortada, Puerto Rico | Sub | 17.9833° N | 66.4500° W
TEC4751 | Playa de Fajardo, Puerto Rico | Sub | 18.3333° N | 65.6333° W
TEC4733 | Playa de Ponce, Puerto Rico | Sub | 17.9667° N | 66.6167° W
8447291 | Pleasant Bay, Cape Cod, Massachusetts | Sub | 41.7367° N | 69.9817° W
9445293 | Pleasant Harbor, Washington | Sub | 47.6650° N | 122.9120° W
8662670 | Pleasant Hill Landing, Santee River, South Carolina | Sub | 33.2450° N | 79.5217° W
ACT7006_1 | Pleasant Point (Depth 12ft), Stono River, South Carolina Current | Sub | 32.7500° N | 80.1333° W
8534657 | Pleasantville, Lakes Bay, Great Egg Harbor Inlet, New Jersey | Sub | 39.3817° N | 74.5183° W
8511236 | Plum Gut Harbor, Plum Island, Long Island, New York | Ref | 41.1717° N | 72.2050° W
8511236 | Plum Gut Harbor, Plum Island, Long Island, New York (sub) | Sub | 41.1717° N | 72.2050° W
8441241 | Plum Island Sound (south end), Massachusetts | Ref | 42.7101° N | 70.7886° W
8441241 | Plum Island Sound (south end), Massachusetts (sub) | Sub | 42.7101° N | 70.7886° W
8440452 | Plum Island, Merrimack River Entrance, Merrimack River, Massachusetts | Ref | 42.8167° N | 70.8200° W
8440452 | Plum Island, Merrimack River Entrance, Merrimack River, Massachusetts (sub) | Sub | 42.8167° N | 70.8200° W
ACT4901_1 | Plum Point, 1.4 miles ESE of, Chesapeake Bay, Maryland Current | Sub | 38.6125° N | 76.4775° W
ACT4921_1 | Plum Point, 2.1 n.mi. NNE of (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 38.6450° N | 76.4872° W
8517531 | Plumb Beach Channel, Jamaica Bay, New York | Sub | 40.5850° N | 73.9250° W
8446493 | Plymouth Harbor, Plymouth, Cape Cod Bay, Massachusetts | Ref | 41.9600° N | 70.6617° W
8446493 | Plymouth Harbor, Plymouth, Cape Cod Bay, Massachusetts (sub) | Sub | 41.9600° N | 70.6617° W
PCT1166_1 | Point Adams, NNE OF (Depth 14ft), Oregon Current | Sub | 46.2278° N | 123.9675° W
TWC0881 | Point Adams, Oregon | Sub | 46.2000° N | 123.9500° W
9452516 | Point Adolphus, Icy Strait, Alaska | Sub | 58.2867° N | 135.8030° W
PCT3741_1 | Point Alexander, Wrangell Narrows, Alaska Current | Sub | 56.5103° N | 132.9583° W
PCT3326_1 | Point Arboleda, 1 mile west of, Alaska Current | Sub | 55.3167° N | 133.4833° W
PCT3876_1 | Point Arden, Stephens Passage, Alaska Current | Sub | 58.1500° N | 134.1333° W
TWC0771 | Point Arena, California | Sub | 38.9500° N | 123.7333° W
TWC0473 | Point Arguello, California | Sub | 34.5833° N | 120.6500° W
8764256 | Point Au Fer, Atchafalaya Bay, Louisiana | Sub | 29.3333° N | 91.3533° W
PCT4116_1 | Point Augusta, ESE of (Depth 70ft), Chatham Strait, Alaska Current | Sub | 58.0250° N | 134.8733° W
9495048 | Point Barrow, Alaska | Sub | 71.3600° N | 156.3530° W
8770557 | Point Barrow, Trinity Bay, Galveston Bay, Texas | Sub | 29.7400° N | 94.8317° W
PCT4306_1 | Point Benham, 1 mile east of, Peril Strait, Alaska Current | Sub | 57.4833° N | 135.1833° W
9414906 | Point Bonita, Bonita Cove, San Francisco Bay, California | Sub | 37.8183° N | 122.5280° W
9441156 | Point Brown, Grays Harbor, Washington | Sub | 46.9500° N | 124.1280° W
9415227 | Point Buckler, Suisun Bay, California | Sub | 38.1000° N | 122.0330° W
PCT4086_1 | Point Caution, 3 miles west of, Chatham Strait, Alaska Current | Sub | 57.2500° N | 134.7333° W
8723691 | Point Charles, Key Largo, Florida | Sub | 25.0817° N | 80.4500° W
9414837 | Point Chauncey, San Francisco Bay, California | Sub | 37.8917° N | 122.4430° W
8764634 | Point Chevreuil, Atchafalaya Bay, Louisiana | Sub | 29.5183° N | 91.5550° W
8733821 | Point Clear, Mobile Bay, Alabama | Ref | 30.4866° N | 87.9345° W
PCT2811_1 | Point Davidson, 1 mile south of, Felice Strait, Alaska Current | Sub | 54.9833° N | 131.6000° W
PCT3746_1 | Point Deception, Wrangell Narrows, Alaska Current | Sub | 56.5333° N | 132.9667° W
PCT4301_1 | Point Elizabeth, 1 mile northeast of, Peril Strait, Alaska Current | Sub | 57.5167° N | 135.2667° W
TWC1783 | Point Elizabeth, Alaska | Sub | 57.5167° N | 135.2833° W
PCT1161_1 | Point Ellice, east of (Depth 17ft), Washington Current | Sub | 46.2417° N | 123.8483° W
PCT4071_1 | Point Ellis, 4 miles west of, Chatham Strait, Alaska Current | Sub | 56.5667° N | 134.4500° W
9454814 | Point Elrington, Elrington Island, Prince William Sound, Alaska | Ref | 59.9383° N | 148.2270° W
9454814 | Point Elrington, Elrington Island, Prince William Sound, Alaska (sub) | Sub | 59.9383° N | 148.2270° W
PCT3841_1 | Point Gambier, 2 miles east of, Stephens Passage, Alaska Current | Sub | 57.4333° N | 133.7667° W
ACT1741_1 | Point Gammon, 1.2 miles south of, Nantucket Sound, Massachusetts Current | Sub | 41.5883° N | 70.2567° W
PCT4081_1 | Point Gardner Light, 2 miles west of, Chatham Strait, Alaska Current | Sub | 57.0167° N | 134.6667° W
9441627 | Point Grenville, Washington | Sub | 47.3033° N | 124.2700° W
9451005 | Point Harrington, Clarence Strait, Alaska | Ref | 56.1783° N | 132.6970° W
9451005 | Point Harrington, Clarence Strait, Alaska (sub) | Sub | 56.1783° N | 132.6970° W
9454671 | Point Helen, Knight Island, Alaska | Sub | 60.1533° N | 147.7670° W
PCT3096_1 | Point Highfield, Alaska Current | Sub | 56.5000° N | 132.3833° W
9491873 | Point Hope, Alaska | Ref | 68.3417° N | 166.8080° W
PCT3846_1 | Point Hugh, Stephens Passage, Alaska Current | Sub | 57.6167° N | 133.7667° W
9414843 | Point Isabel, San Francisco Bay, California | Sub | 37.8983° N | 122.3200° W
8455083 | Point Judith, Harbor of Refuge, Rhode Island | Ref | 41.3633° N | 71.4900° W
8455083 | Point Judith, Harbor of Refuge, Rhode Island (sub) | Sub | 41.3633° N | 71.4900° W
9453210 | Point Latouche, Yakutat Bay, Alaska | Sub | 59.9033° N | 139.6270° W
9451263 | Point Lockwood, Woewodski Island, Wrangell Narrows, Alaska | Ref | 56.5583° N | 132.9630° W
9451263 | Point Lockwood, Woewodski Island, Wrangell Narrows, Alaska (sub) | Sub | 56.5583° N | 132.9630° W
PCT3751_1 | Point Lockwood, Wrangell Narrows, Alaska Current | Sub | 56.5558° N | 132.9618° W
PCT0026_1 | Point Loma Light, 0.8 nmi. east of (Depth 15ft), San Diego Bay, California Current | Sub | 32.6658° N | 117.2262° W
PCT0026_2 | Point Loma Light, 0.8 nmi. east of (Depth 33ft), San Diego Bay, California Current | Sub | 32.6658° N | 117.2262° W
TWC0405 | Point Loma, California | Sub | 32.6667° N | 117.2333° W
8578002 | Point Lookout, Chesapeake Bay, Maryland | Sub | 38.0400° N | 76.3233° W
8516402 | Point Lookout, Long Island, New York | Ref | 40.5939° N | 73.5840° W
PCT2626_1 | Point Marsh, 5 miles south from, Dixon Entrance, Alaska Current | Sub | 54.6333° N | 132.3000° W
PCT2876_1 | Point McCartey Light, Nichols Passage, Alaska Current | Sub | 55.1167° N | 131.7000° W
TWC1173 | Point Migley, Hale Passage, Washington | Sub | 48.7500° N | 122.7167° W
8530743 | Point No Point, Passaic River, New Jersey | Sub | 40.7317° N | 74.1167° W
9414881 | Point Orient, San Francisco Bay, California | Sub | 37.9583° N | 122.4250° W
9447934 | Point Partridge, Whidbey Island, Strait of Juan de Fuca, Washington | Sub | 48.2317° N | 122.7650° W
ACT5946_1 | Point Patience, 0.1 mile southwest of (Depth 15ft), Patuxent River, Maryland Current | Sub | 38.3283° N | 76.4867° W
PCT2676_1 | Point Phipp, Pearse Canal, Alaska Current | Sub | 54.7833° N | 130.6333° W
8726454 | Point Pinellas, Florida | Sub | 27.7017° N | 82.6400° W
9455866 | Point Possession, Alaska | Ref | 61.0367° N | 150.4130° W
9449639 | Point Roberts, Strait of Georgia, Washington | Ref | 48.9750° N | 123.0830° W
9414402 | Point San Bruno, San Francisco Bay, California | Sub | 37.6500° N | 122.3770° W
9415009 | Point San Pedro, San Pablo Bay, California | Sub | 37.9933° N | 122.4470° W
9414873 | Point San Quentin, San Francisco Bay, California | Sub | 37.9450° N | 122.4750° W
9469237 | Point Spencer, Port Clarence, Norton Sound, Alaska | Ref | 65.2567° N | 166.8470° W
9469237 | Point Spencer, Port Clarence, Norton Sound, Alaska (sub) | Sub | 65.2567° N | 166.8470° W
PCT3551_1 | Point St. Albans, 3 miles SSE of, Sumner Strait, Alaska Current | Sub | 56.0333° N | 133.9500° W
PCT3556_1 | Point St. Albans, 4 miles east of, Sumner Strait, Alaska Current | Sub | 56.0833° N | 133.8500° W
9450943 | Point St. Albans, Alaska | Sub | 56.0817° N | 133.9700° W
PCT2921_1 | Point Sykes, Behm Canal, Alaska Current | Sub | 55.2000° N | 131.1167° W
PCT4091_1 | Point Thatcher, 3 miles east of, Chatham Strait, Alaska Current | Sub | 57.4167° N | 134.7333° W
TWC1735 | Point Thatcher, Alaska | Sub | 57.4167° N | 134.8500° W
9446025 | Point Vashon, Vashon Island, Puget Sound, Washington | Sub | 47.5117° N | 122.4630° W
PCT3066_1 | Point Warde, Ernest Sound, Alaska Current | Sub | 56.1833° N | 131.9667° W
ACT8306_1 | Point Ybel, 0.4 mile northwest of, Florida Current | Sub | 26.4567° N | 82.0187° W
TEC4207 | Point Ybel, San Carlos Bay entrance, Florida | Sub | 26.4500° N | 82.0167° W
8740448 | Point of Pines, Bayou Cumbest, Mississippi | Sub | 30.3867° N | 88.4400° W
8667178 | Point of Pines, North Edisto River, South Carolina | Sub | 32.5850° N | 80.2283° W
9450862 | Pole Anchorage, Kosciusko Island, Alaska | Sub | 55.9550° N | 133.8100° W
ACT1616_1 | Pollock Rip Channel (Butler Hole), Massachusetts Current | Ref | 41.5500° N | 69.9833° W
ACT1611_1 | Pollock Rip Channel, east end, Nantucket Sound entrance, Massachusetts Current | Sub | 41.5650° N | 69.9233° W
8538875 | Pompeston Creek, New Jersey | Sub | 40.0133° N | 75.0083° W
8721147 | Ponce De Leon Inlet South, Florida | Ref | 29.0633° N | 80.9150° W
8721147 | Ponce De Leon Inlet South, Florida (sub) | Sub | 29.0633° N | 80.9150° W
8721138 | Ponce Inlet, Halifax River, Florida | Sub | 29.0817° N | 80.9367° W
8574459 | Pond Point (Aberdeen P.G.), Bush River, Chesapeake Bay, Maryland | Ref | 39.3883° N | 76.2550° W
8574459 | Pond Point (Aberdeen P.G.), Bush River, Chesapeake Bay, Maryland (sub) | Sub | 39.3883° N | 76.2550° W
8512451 | Ponquoque Point, Shinnecock Bay, New York | Ref | 40.8500° N | 72.5033° W
ACT5086_1 | Pooles Island 2.0 n.mi. SSW of (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 39.2463° N | 76.2967° W
ACT5091_1 | Pooles Island, 0.8 mile south of, Chesapeake Bay, Maryland Current | Sub | 39.2617° N | 76.2733° W
ACT5101_1 | Pooles Island, 1.6 n.mi. east of (Depth 16ft), Chesapeake Bay, Maryland Current | Sub | 39.2745° N | 76.2262° W
ACT5081_1 | Pooles Island, 4 miles southwest of, Chesapeake Bay, Maryland Current | Sub | 39.2267° N | 76.3313° W
ACT4926_1 | Poplar Island, 2.2 n.mi. WSW of (Depth 14ft), Chesapeake Bay, Maryland Current | Sub | 38.7562° N | 76.4295° W
ACT4931_1 | Poplar Island, 3.0 n.mi. WSW of (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 38.7497° N | 76.4455° W
ACT4931_2 | Poplar Island, 3.0 n.mi. WSW of (Depth 48ft), Chesapeake Bay, Maryland Current | Sub | 38.7497° N | 76.4455° W
8572271 | Poplar Island, Chesapeake Bay, Maryland | Ref | 38.7583° N | 76.3750° W
ACT6046_1 | Poplar Island, east of south end, Eastern Bay, Maryland Current | Sub | 38.7483° N | 76.3533° W
ACT6016_1 | Poplar Point, south of, Choptank River, Maryland Current | Sub | 38.6753° N | 75.9663° W
PCT5406_1 | Popof Strait, Shumagin Islands, Alaska Current | Sub | 55.3333° N | 160.5167° W
9466057 | Popokamute (Kokokamute), Kuskokwim River, Alaska | Ref | 60.1233° N | 162.5004° W
8447742 | Poponesset Island, Poponesset Bay, Nantucket Sound, Massachusetts | Sub | 41.5867° N | 70.4633° W
8744671 | Popps Ferry, Back Bay, Biloxi, Mississippi | Ref | 30.4133° N | 88.9750° W
8724196 | Porpoise Key, Big Spanish Channel, Florida | Sub | 24.7183° N | 81.3517° W
9451054 | Port Alexander, Baranof Island, Alaska | Ref | 56.2467° N | 134.6470° W
9451054 | Port Alexander, Baranof Island, Alaska (sub) | Sub | 56.2467° N | 134.6470° W
9450768 | Port Alice, Heceta Island, Davidson Inlet, Alaska | Sub | 55.8117° N | 133.6050° W
1611347 | Port Allen, Hanapepe Bay, Kauai Island, Hawaii | Ref | 21.9033° N | 159.5920° W
1611347 | Port Allen, Hanapepe Bay, Kauai Island, Hawaii (sub) | Sub | 21.9033° N | 159.5920° W
9444090 | Port Angeles, Strait Of Juan De Fuca, Washington | Ref | 48.1247° N | 123.4411° W
9444090 | Port Angeles, Strait Of Juan De Fuca, Washington (sub) | Sub | 48.1247° N | 123.4411° W
8775270 | Port Aransas (H. Caldwell Pier), Texas | Ref | 27.8267° N | 97.0500° W
8775237 | Port Aransas, Texas | Ref | 27.8397° N | 97.0725° W
9454673 | Port Audrey, Knight Island, Alaska | Sub | 60.3433° N | 147.7680° W
9451082 | Port Beauclerc, Kuiu Island, Alaska | Sub | 56.2883° N | 133.9620° W
9445913 | Port Blakely, Puget Sound, Washington | Sub | 47.5967° N | 122.5100° W
8725577 | Port Boca Grande, Charlotte Harbor, Florida | Ref | 26.7200° N | 82.2583° W
8771328 | Port Bolivar, Galveston Bay, Texas | Ref | 29.3650° N | 94.7800° W
8771328 | Port Bolivar, Galveston Bay, Texas (sub) | Sub | 29.3650° N | 94.7800° W
9454511 | Port Chalmers, Montague Island, Alaska | Sub | 60.2418° N | 147.2490° W
9455428 | Port Chatham, Cook Inlet, Alaska | Sub | 59.2133° N | 151.7280° W
9415144 | Port Chicago, Suisun Bay, California | Ref | 38.0560° N | 122.0395° W
8415933 | Port Clyde, St. George River, Maine | Sub | 43.9250° N | 69.2600° W
8574008 | Port Deposit, Susquehanna River, Maryland | Sub | 39.6033° N | 76.1133° W
8760579 | Port Eads, South Pass, Mississippi River, Louisiana | Sub | 29.0150° N | 89.1600° W
8537147 | Port Elizabeth, Manumuskin River, Maurice River, New Jersey | Sub | 39.3133° N | 74.9850° W
8530882 | Port Elizabeth, New Jersey | Sub | 40.6733° N | 74.1400° W
TWC1887 | Port Etches, Hinchinbrook Island, Alaska | Sub | 60.3333° N | 146.5500° W
8722951 | Port Everglades, Turning Basin, Florida | Sub | 26.0917° N | 80.1233° W
8762075 | Port Fourchon, Belle Pass, Louisiana | Ref | 29.1142° N | 90.1993° W
9445059 | Port Gamble, Washington | Sub | 47.8583° N | 122.5800° W
9455437 | Port Graham, Cook Inlet, Alaska | Sub | 59.3500° N | 151.8267° W
PCT5771_1 | Port Heiden, Alaska Current | Sub | 56.9833° N | 158.8833° W
9464096 | Port Heiden, Bristol Bay, Alaska | Sub | 56.9333° N | 158.7280° W
9457479 | Port Hobron, Sitkalidak Island, Alaska | Sub | 57.1633° N | 153.1520° W
TWC1673 | Port Houghton, Robert Islands, Alaska | Sub | 57.3000° N | 133.4667° W
9411065 | Port Hueneme, California | Sub | 34.1483° N | 119.2030° W
ACT8901_1 | Port Ingleside (Depth 5ft), Texas Current | Sub | 27.8150° N | 97.2300° W
8775283 | Port Ingleside, Corpus Christi Bay, Texas | Ref | 27.8217° N | 97.2033° W
8779770 | Port Isabel, Laguna Madre, Texas | Ref | 26.0612° N | 97.2155° W
8779770 | Port Isabel, Laguna Madre, Texas (sub) | Sub | 26.0612° N | 97.2155° W
8519200 | Port Ivory, Howland Hook, Arthur Kill, New York | Sub | 40.6450° N | 74.1800° W
8514594 | Port Jefferson Harbor entrance, Long Island, New York | Sub | 40.9717° N | 73.0917° W
8514560 | Port Jefferson, Long Island, New York | Sub | 40.9500° N | 73.0767° W
9445683 | Port Jefferson, Puget Sound, Washington | Sub | 47.7467° N | 122.4770° W
8722968 | Port Laudania, Dania cut-off Canal, Florida | Sub | 26.0600° N | 80.1300° W
8773259 | Port Lavaca, Lavaca Causeway, Matagorda Bay, Texas | Ref | 28.6406° N | 96.6098° W
9457391 | Port Lions, Kodiak Island, Alaska | Ref | 57.8735° N | 152.8671° W
9445017 | Port Ludlow, Washington | Sub | 47.9250° N | 122.6800° W
9455934 | Port Mackenzie, Cook Inlet, Alaska | Ref | 61.2683° N | 149.9170° W
9445753 | Port Madison, Puget Sound, Washington | Sub | 47.7050° N | 122.5250° W
9451093 | Port Malmesbury, Kuiu Island, Alaska | Sub | 56.3050° N | 134.2380° W
ACT8506_1 | Port Manatee Channel entrance (Depth 15ft), Tampa Bay, Florida Current | Sub | 27.6620° N | 82.5992° W
ACT8511_1 | Port Manatee Channel, marker '4' (Depth 15ft), Tampa Bay, Florida Current | Sub | 27.6535° N | 82.5898° W
8726384 | Port Manatee, Tampa Bay, Florida | Ref | 27.6383° N | 82.5625° W
8726384 | Port Manatee, Tampa Bay, Florida (sub) | Sub | 27.6383° N | 82.5625° W
TWC1593 | Port McArthur, Kuiu Island, Alaska | Sub | 56.0667° N | 134.1167° W
9463502 | Port Moller, Bristol Bay, Alaska | Ref | 55.9857° N | 160.5739° W
8518639 | Port Morris (Stony Point), East River, New York | Ref | 40.8017° N | 73.9067° W
8518639 | Port Morris (Stony Point), East River, New York (sub) | Sub | 40.8017° N | 73.9067° W
8530884 | Port Newark Terminal, New Jersey | Sub | 40.6900° N | 74.1333° W
8773701 | Port O'Connor, Matagorda Bay, Texas | Ref | 28.4459° N | 96.3956° W
9431647 | Port Orford, Oregon | Ref | 42.7390° N | 124.4983° W
9451095 | Port Protection, Prince of Wales Island., Alaska | Sub | 56.3083° N | 133.6000° W
8531142 | Port Reading, Arthur Kill, New York | Ref | 40.5550° N | 74.2450° W
TPT2725 | Port Rhin, Mili Atoll, Marshall Islands | Sub | 6.2333° N | 171.8000° E
ACT7186_1 | Port Royal Plantation Tower, east of (Depth 15ft), South Carolina Current | Sub | 32.2233° N | 80.6567° W
8669167 | Port Royal Plantation, Hilton Head Island, South Carolina | Sub | 32.2200° N | 80.6683° W
8635299 | Port Royal, Rappahannock River, Virginia | Sub | 38.1733° N | 77.1900° W
8728912 | Port Saint Joe, St. Joseph Bay, Florida | Ref | 29.8150° N | 85.3133° W
8728912 | Port Saint Joe, St. Joseph Bay, Florida (sub) | Sub | 29.8150° N | 85.3133° W
8722383 | Port Salerno, Manatee Pocket, St. Lucie River, Florida | Sub | 27.1517° N | 80.1950° W
9412110 | Port San Luis, California | Ref | 35.1688° N | 120.7542° W
9452082 | Port Snettisham, Crib Point, Alaska | Sub | 58.0967° N | 133.7420° W
TWC1687 | Port Snettisham, Point Styleman, Alaska | Sub | 57.9667° N | 133.8833° W
8726607 | Port Tampa, Old Tampa Bay, Florida | Ref | 27.8578° N | 82.5528° W
8726607 | Port Tampa, Old Tampa Bay, Florida (sub) | Sub | 27.8578° N | 82.5528° W
9444900 | Port Townsend (Point Hudson), Admiralty Inlet, Washington | Ref | 48.1129° N | 122.7595° W
PCT1561_1 | Port Townsend Canal, Admiralty Inlet, Washington Current | Sub | 48.0333° N | 122.7333° W
PCT4066_1 | Port Walter Light, 3 miles east of, Chatham Strait, Alaska Current | Sub | 56.3833° N | 134.5333° W
9451151 | Port Walter, Baranof Island, Alaska | Sub | 56.3917° N | 134.6600° W
8516761 | Port Washington, Manhasset Bay, Long Island, New York | Ref | 40.8317° N | 73.7033° W
8516761 | Port Washington, Manhasset Bay, Long Island, New York (sub) | Sub | 40.8317° N | 73.7033° W
ACT7431_1 | Port Wentworth, 0.2 mile above, Savannah River, Georgia Current | Sub | 32.1467° N | 81.1400° W
8670424 | Port Wentworth, Savannah River, Georgia | Ref | 32.1433° N | 81.1417° W
8670424 | Port Wentworth, Savannah River, Georgia (sub) | Sub | 32.1433° N | 81.1417° W
8722588 | Port of West Palm Beach, Florida | Ref | 26.7700° N | 80.0517° W
8722588 | Port of West Palm Beach, Florida (sub) | Sub | 26.7700° N | 80.0517° W
TWC1663 | Portage Bay, Kupreanof Island, Frederick Sound, Alaska | Sub | 57.0000° N | 133.3167° W
8418031 | Portland Head Light, Casco Bay, Maine | Sub | 43.6233° N | 70.2067° W
PCT2666_1 | Portland Inlet, 2 miles S. of Wales Pt, Dixon Entrance, Alaska Current | Sub | 54.6667° N | 130.4833° W
8418150 | Portland, Casco Bay, Maine | Ref | 43.6567° N | 70.2467° W
9439221 | Portland, Morrison Street Bridge, Oregon | Ref | 45.5100° N | 122.6730° W
8638660 | Portsmouth, Naval Shipyard, Elizabeth River, Virginia | Ref | 36.8217° N | 76.2933° W
8638660 | Portsmouth, Naval Shipyard, Elizabeth River, Virginia (sub) | Sub | 36.8217° N | 76.2933° W
8423745 | Portsmouth, Portsmouth Harbor, New Hampshire | Sub | 43.0783° N | 70.7517° W
ACT5866_1 | Potomac River Bridge, 0.4 mile south of, Potomac River, Maryland Current | Sub | 38.3563° N | 76.9867° W
9414334 | Potrero Point, San Francisco Bay, California | Sub | 37.7583° N | 122.3830° W
8518945 | Poughkeepsie, Hudson River, New York | Sub | 41.7000° N | 73.9333° W
9445719 | Poulsbo, Liberty Bay, Puget Sound, Washington | Sub | 47.7250° N | 122.6380° W
8418137 | Presumpscot River Bridge, Casco Bay, Maine | Sub | 43.6867° N | 70.2467° W
8664801 | Price Creek, North Capers Island, South Carolina | Sub | 32.8817° N | 79.6583° W
8671315 | Priest Landing, Wilmington River, Georgia | Ref | 31.9633° N | 81.0117° W
9447717 | Priest Point, Washington | Ref | 48.0349° N | 122.2272° W
8417948 | Prince Point, Casco Bay, Maine | Sub | 43.7617° N | 70.1733° W
8519726 | Princes Bay, New Jersey | Sub | 40.5117° N | 74.2000° W
9410971 | Prisoners Harbor, Santa Cruz Island, California | Sub | 34.0200° N | 119.6830° W
9415149 | Prisoners Point, San Joaquin River, California | Sub | 38.0617° N | 121.5550° W
PCT3806_1 | Prolewy Rocks, Wrangell Narrows, Alaska Current | Sub | 56.8223° N | 132.9483° W
8412932 | Prospect Harbor, Maine | Sub | 44.4000° N | 68.0217° W
PCT5796_1 | Protection Point, 2.5 miles east of, Alaska Current | Sub | 58.5000° N | 158.6167° W
9465056 | Protection Point, Nushagak Bay, Alaska | Ref | 58.5000° N | 158.7120° W
8454000 | Providence, State Pier no.1, Narragansett Bay, Rhode Island | Ref | 41.8067° N | 71.4006° W
8454000 | Providence, State Pier no.1, Narragansett Bay, Rhode Island (sub) | Sub | 41.8067° N | 71.4006° W
8446121 | Provincetown, Cape Cod, Massachusetts | Ref | 42.0496° N | 70.1822° W
8446121 | Provincetown, Cape Cod, Massachusetts (sub) | Sub | 42.0496° N | 70.1822° W
9451936 | Provorotni Island, Alaska | Ref | 57.5150° N | 135.5550° W
9451936 | Provorotni Island, Alaska (sub) | Sub | 57.5150° N | 135.5550° W
8452555 | Prudence Island, (south end), Narragansett Bay, Rhode Island | Sub | 41.5800° N | 71.3217° W
9497649 | Prudhoe Bay #2, Alaska | Ref | 70.3883° N | 148.5100° W
9497645 | Prudhoe Bay, Alaska | Ref | 70.4114° N | 148.5318° W
9458209 | Puale Bay, Alaska | Ref | 57.7067° N | 155.3930° W
9458209 | Puale Bay, Alaska (sub) | Sub | 57.7067° N | 155.3930° W
8570649 | Public Landing, Chincoteague Bay, Maryland | Ref | 38.1483° N | 75.2850° W
8570649 | Public Landing, Chincoteague Bay, Maryland (sub) | Sub | 38.1483° N | 75.2850° W
8638489 | Puddledock Sand & Gravel, Appomattox River, Virginia | Ref | 37.2667° N | 77.3717° W
8638489 | Puddledock Sand & Gravel, Appomattox River, Virginia (sub) | Sub | 37.2667° N | 77.3717° W
TEC4743 | Puerto Ferro, Isla de Vieques, Puerto Rico | Sub | 18.1000° N | 65.4333° W
TEC4739 | Puerto Maunabo, Puerto Rico | Sub | 18.0000° N | 65.8833° W
9759189 | Puerto Real, Puerto Rico | Ref | 18.0748° N | 67.1888° W
1613155 | Pukoo Harbor, Molokai Island, Hawaii | Sub | 21.0717° N | 156.8000° W
TPT2651 | Pulap Atoll, Chuuk, FSM | Sub | 7.6333° N | 149.4167° E
8414888 | Pulpit Harbor, North Haven Island, Penobscot Bay, Maine | Ref | 44.1567° N | 68.8867° W
8724373 | Pumpkin Key, Bow Channel, Florida | Sub | 24.7167° N | 81.5617° W
8723506 | Pumpkin Key, south end, Card Sound, Florida | Ref | 25.3250° N | 80.2933° W
8725744 | Punta Gorda, Charlotte Harbor, Florida | Sub | 26.9283° N | 82.0650° W
9759421 | Punta Guanajibo, Mayagüez, Puerto Rico | Ref | 18.1650° N | 67.1817° W
TEC4745 | Punta Mulas, Isla de Vieques, Puerto Rico | Sub | 18.1500° N | 65.4333° W
ACT8921_1 | Punta Ostiones, 1.5 miles west of, Puerto Rico Current | Sub | 18.0867° N | 67.2267° W
8725391 | Punta Rassa, San Carlos Bay, Florida | Ref | 26.4883° N | 82.0133° W
8668701 | Purrysburg Landing, Savannah River, South Carolina | Sub | 32.3033° N | 81.1217° W
9419945 | Pyramid Point, Smith River, California | Ref | 41.9453° N | 124.2009° W
9465123 | Pyrite Point, Bristol Bay, Alaska | Ref | 58.6200° N | 161.5420° W
ACT5886_1 | Quantico Creek entrance, Potomac River, Virginia Current | Sub | 38.5283° N | 77.2883° W
8634689 | Quantico, Potomac River, Virginia | Sub | 38.5200° N | 77.2867° W
ACT5881_1 | Quantico, Potomac River, Virginia Current | Sub | 38.5217° N | 77.2767° W
PCT0051_1 | Quarantine Station, La Playa, San Diego Bay, California Current | Sub | 32.7000° N | 117.2333° W
8761557 | Quatre Bayous Pass, Louisiana | Sub | 29.3100° N | 89.8533° W
8779724 | Queen Isabella Causeway (east end), Texas | Sub | 26.0783° N | 97.1700° W
8779739 | Queen Isabella Causeway (west end), Texas | Sub | 26.0717° N | 97.1917° W
8518687 | Queensboro Bridge, East River, New York | Ref | 40.7583° N | 73.9583° W
8518687 | Queensboro Bridge, East River, New York (sub) | Sub | 40.7583° N | 73.9583° W
8572867 | Queenstown, Chester River, Maryland | Sub | 38.9967° N | 76.1583° W
8448251 | Quicks Hole, North side, Massachusetts | Sub | 41.4483° N | 70.8567° W
9445272 | Quilcene, Quilcene Bay, Dabob Bay, Washington | Sub | 47.8000° N | 122.8580° W
8663535 | Quinby Creek bridge, East Branch, Cooper River, South Carolina | Sub | 33.0950° N | 79.8083° W
9465831 | Quinhagak (Kwinak), Kushkokwin River, Alaska | Ref | 59.7506° N | 161.9154° W
PCT1201_1 | Quinn Island, Prairie Channel (Depth 8ft), Washington Current | Sub | 46.2372° N | 123.5033° W
8537889 | Quinton, Alloway Creek, New Jersey | Sub | 39.5483° N | 75.4150° W
TWC0413 | Quivira Basin, Mission Bay, California | Sub | 32.7667° N | 117.2333° W
8454049 | Quonset Point, Rhode Island | Ref | 41.5868° N | 71.4110° W
8667508 | RR. Bridge, Hall Island, Broad River, South Carolina | Sub | 32.5217° N | 80.8383° W
8764706 | Rabbit Island, 5 miles south of, Atchafalaya Bay, Louisiana | Sub | 29.4200° N | 91.5933° W
ACT6551_1 | Rabbit Island, northwest of, Winyah Bay, South Carolina Current | Sub | 33.3395° N | 79.2813° W
8537489 | Raccoon Ditch, Newport Meadows, Stow Creek, Delaware River, New Jersey | Sub | 39.4217° N | 75.3817° W
ACT7601_1 | Raccoon Key & Egg Island Shoal, between (Depth 10ft), Ossabaw Sound, Georgia Current | Sub | 31.8428° N | 81.0675° W
ACT7581_1 | Raccoon Key (Depth 10ft), Ossabaw Sound, Georgia Current | Sub | 31.8617° N | 81.0550° W
8678124 | Raccoon Key Spit, St. Andrew Sound, Georgia | Ref | 31.0148° N | 81.4560° W
8724311 | Raccoon Key, east side, Florida | Sub | 24.7417° N | 81.4833° W
8763506 | Raccoon Point, Caillou Bay, Louisiana | Sub | 29.0633° N | 90.9617° W
PCT2761_1 | Race Point, 0.7 mile ENE of, Revillagigedo Channel, Alaska Current | Sub | 55.2858° N | 131.5460° W
8720625 | Racy Point, St. Johns River, Florida | Ref | 29.8017° N | 81.5483° W
ACT6381_1 | Radio Island, E of (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.7117° N | 76.6797° W
8723355 | Ragged Key No. 5, Biscayne Bay, Florida | Ref | 25.5233° N | 80.1750° W
8723350 | Ragged Keys, Biscayne Bay, Florida | Sub | 25.5333° N | 80.1717° W
ACT5976_1 | Ragged Point, 1.5 miles east of, Little Choptank River, Maryland Current | Sub | 38.5300° N | 76.2442° W
8635485 | Ragged Point, Coles Neck, Potomac River, Virginia | Sub | 38.1417° N | 76.6133° W
8531077 | Rahway River, RR. Bridge, Arthur Kill, New Jersey | Sub | 40.5983° N | 74.2317° W
8770520 | Rainbow Bridge, Neches River, Texas | Ref | 29.9800° N | 93.8817° W
8724239 | Ramrod Key, Newfound Harbor, Florida | Sub | 24.6500° N | 81.4033° W
8724255 | Ramrod Key, Niles Channel Bridge, Florida | Sub | 24.6600° N | 81.4233° W
ACT7296_1 | Ramshorn Creek Light, E of, Cooper River (Depth 6ft), South Carolina Current | Sub | 32.1300° N | 80.8817° W
ACT6536_1 | Range D, off Mosquito Creek, Winyah Bay, South Carolina Current | Sub | 33.2442° N | 79.2058° W
8635257 | Rappahannock Bend, Virginia | Ref | 38.2133° N | 77.2433° W
8635257 | Rappahannock Bend, Virginia (sub) | Sub | 38.2133° N | 77.2433° W
8632837 | Rappahannock Light, Virginia | Ref | 37.5383° N | 76.0150° W
9452128 | Rasp Ledge, Seymour Canal, Alaska | Sub | 57.6783° N | 134.0380° W
ACT6911_1 | Rathall Creek entrance, Wando River, Charleston Harbor, South Carolina Current | Sub | 32.8595° N | 79.8962° W
ACT8436_1 | Rattlesnake Key, 1.1 miles northwest of, Tampa Bay, Florida Current | Sub | 27.5708° N | 82.6438° W
ACT8431_1 | Rattlesnake Key, 3.1 miles west of, Tampa Bay, Florida Current | Sub | 27.5533° N | 82.6883° W
9450815 | Ratz Harbor, Prince of Wales Island, Alaska | Sub | 55.8800° N | 132.5950° W
9462573 | Raven Bay, Unalaska Island, Alaska | Sub | 53.4750° N | 166.8730° W
9440886 | Raymond, Willapa River, Willapa Bay, Washington | Sub | 46.6833° N | 123.7550° W
8779280 | Realitos Peninsula, Texas | Ref | 26.2624° N | 97.2853° W
8658622 | Reaves Point, Cape Fear River, North Carolina | Sub | 34.0033° N | 77.9550° W
ACT6716_1 | Rebellion Reach, 0.8 n.mi. N. of Ft. Sumter, Charleston Harbor, South Carolina Current | Sub | 32.7663° N | 79.8733° W
8531833 | Red Bank, Navesink River, Shrewsbury River, New Jersey | Sub | 40.3550° N | 74.0650° W
8720503 | Red Bay Point, St. Johns River, Florida | Ref | 29.9817° N | 81.6342° W
ACT8061_3 | Red Bay Point, draw bridge (Depth 14ft), St. Johns River, Florida Current | Sub | 29.9850° N | 81.6300° W
ACT8061_1 | Red Bay Point, draw bridge (Depth 4ft), St. Johns River, Florida Current | Sub | 29.9850° N | 81.6300° W
ACT8061_2 | Red Bay Point, draw bridge (Depth 6ft), St. Johns River, Florida Current | Sub | 29.9850° N | 81.6300° W
9451467 | Red Bluff Bay, Baranof Island, Alaska | Ref | 56.8567° N | 134.7230° W
9491094 | Red Dog Dock, Alaska | Ref | 67.5758° N | 164.0644° W
ACT5151_1 | Red Point, 0.2 mile W of, Northeast River (Depth 7ft), Chesapeake Bay, Maryland Current | Sub | 39.5292° N | 75.9847° W
9453208 | Redfield Cove, Yakutat Bay, Alaska | Sub | 59.6117° N | 139.5800° W
8725441 | Redfish Pass, Captiva Island (north end), Florida | Sub | 26.5500° N | 82.1967° W
8726278 | Redfish Point, Manatee River, Florida | Sub | 27.5267° N | 82.4817° W
9457316 | Redfox Bay, Shuyak Strait, Alaska | Sub | 58.4533° N | 152.5950° W
9751540 | Redhook Bay, St. Thomas, Virgin Islands | Sub | 18.3267° N | 64.8517° W
9414523 | Redwood City, Wharf 5, San Francisco Bay, California | Ref | 37.5068° N | 122.2115° W
9414523 | Redwood City, Wharf 5, San Francisco Bay, California (sub) | Sub | 37.5068° N | 122.2115° W
9414501 | Redwood Creek Marker 8, San Francisco Bay, California | Ref | 37.5333° N | 122.1930° W
9414501 | Redwood Creek Marker 8, San Francisco Bay, California (sub) | Sub | 37.5333° N | 122.1930° W
TWC0573 | Redwood Creek entrance (inside), San Francisco Bay, California | Sub | 37.5167° N | 122.2000° W
9433501 | Reedsport, Umpqua River, Oregon | Ref | 43.7083° N | 124.0980° W
8551910 | Reedy Point, C&D Canal, Delaware | Ref | 39.5583° N | 75.5733° W
9462662 | Reef Bight, Alaska | Ref | 54.1307° N | 166.0993° W
9451124 | Reef Point, Stikine Strait, Alaska | Ref | 56.3533° N | 132.5530° W
9451124 | Reef Point, Stikine Strait, Alaska (sub) | Sub | 56.3533° N | 132.5530° W
8557863 | Rehoboth Beach, Delaware | Sub | 38.7200° N | 75.0833° W
9451148 | Reid Bay, Alaska | Sub | 56.3883° N | 133.8830° W
ACT6901_1 | Remley Point, 0.2 mile northwest of, Wando River, South Carolina Current | Sub | 32.8162° N | 79.9095° W
9419551 | Requa Dock, California | Ref | 41.5450° N | 124.0700° W
8631234 | Revel Island, Revel Creek, Virginia | Sub | 37.4967° N | 75.6833° W
9415320 | Reynolds, Tomales Bay, California | Sub | 38.1467° N | 122.8830° W
8661367 | Rhems, Black Mingo Creek, Black River, Great Pee Dee River, South Carolina | Sub | 33.6033° N | 79.4267° W
8575787 | Rhode River (County Wharf), Chesapeake Bay, Maryland | Sub | 38.8867° N | 76.5400° W
8728949 | Richardson Hammock, St. Joseph Bay, Florida | Ref | 29.6900° N | 85.3633° W
9449982 | Richardson, Lopez Island, San Juan Channel, Washington | Ref | 48.4467° N | 122.9000° W
8636941 | Richmond Deepwater Terminal, James River, Virginia | Ref | 37.4596° N | 77.4208° W
9414849 | Richmond Inner Harbor, San Francisco Bay, California | Sub | 37.9100° N | 122.3580° W
8663665 | Richmond Plantation, East Branch, Cooper River, South Carolina | Sub | 33.0767° N | 79.8550° W
8638495 | Richmond River Locks, James River, Virginia | Ref | 37.5250° N | 77.4200° W
8638495 | Richmond River Locks, James River, Virginia (sub) | Sub | 37.5250° N | 77.4200° W
8417208 | Richmond, Kennebec River, Maine | Ref | 44.0883° N | 69.7983° W
8530398 | Ridgefield Park, Hackensack River, New Jersey | Sub | 40.8500° N | 74.0300° W
8536801 | Riggins Ditch, 0.5 n.mi. above entrance, Delaware Bay, New Jersey | Sub | 39.2000° N | 74.9700° W
8536855 | Riggins Ditch, Heislerville, Delaware Bay, New Jersey | Sub | 39.2183° N | 74.9800° W
ACT3366_1 | Rikers I. chan., off La Guardia Field, East River, New York Current | Sub | 40.7833° N | 73.8833° W
9411270 | Rincon Island, Mussel Shoals, Santa Barbara Channel, California | Ref | 34.3483° N | 119.4430° W
9411270 | Rincon Island, Mussel Shoals, Santa Barbara Channel, California (sub) | Sub | 34.3483° N | 119.4430° W
9414317 | Rincon Point, Pier 22½, San Francisco Bay, California | Ref | 37.7900° N | 122.3870° W
9414317 | Rincon Point, Pier 22½, San Francisco Bay, California (sub) | Sub | 37.7900° N | 122.3870° W
9432436 | Rink Creek Entrance, Coquille River, Oregon | Ref | 43.1579° N | 124.1818° W
9415316 | Rio Vista, Sacramento River, California | Ref | 38.1450° N | 121.6920° W
9415316 | Rio Vista, Sacramento River, California (sub) | Sub | 38.1450° N | 121.6920° W
9453456 | Riou Bay, Alaska | Sub | 59.8850° N | 141.4570° W
8534691 | River Bend Marina, Great Egg Harbor River, New Jersey | Sub | 39.3683° N | 74.7167° W
8518905 | Riverdale, Hudson River, New York | Ref | 40.9033° N | 73.9167° W
8518905 | Riverdale, Hudson River, New York (sub) | Sub | 40.9033° N | 73.9167° W
8440889 | Riverside, Merrimack River, Massachusetts | Ref | 42.7633° N | 71.0767° W
8440889 | Riverside, Merrimack River, Massachusetts (sub) | Sub | 42.7633° N | 71.0767° W
8578853 | Riverside, Potomac River, Maryland | Sub | 38.3867° N | 77.1450° W
8532611 | Riviera Beach, Manasquan River, New Jersey | Sub | 40.0967° N | 74.0867° W
8724529 | Riviera Canal, Key West, Florida | Sub | 24.5650° N | 81.7517° W
8636969 | Roane Point, York River, Virginia | Sub | 37.4467° N | 76.7083° W
8652547 | Roanoke Marshes Light, outer coast, North Carolina | Ref | 35.8117° N | 75.7000° W
8652591 | Roanoke Sound Channel, North Carolina | Sub | 35.7983° N | 75.5833° W
8571476 | Roaring Point, Nanticoke River, Maryland | Sub | 38.2617° N | 75.9200° W
TWC0547 | Roberts Landing, 1.3 miles west of, San Francisco Bay, California | Sub | 37.6667° N | 122.2000° W
8417067 | Robinhood, Sasanoa River, Sheepscot River, Maine | Sub | 43.8533° N | 69.7333° W
ACT5106_1 | Robins Point, 0.7 mile ESE of (Depth 5ft), Chesapeake Bay, Maryland Current | Sub | 39.2958° N | 76.2683° W
ACT1846_1 | Robinsons Hole, 1.2 miles southeast of, Vineyard Sound, Massachusetts Current | Sub | 41.4350° N | 70.7800° W
9449834 | Roche Harbor, San Juan Island, Haro Strait, Washington | Sub | 48.6100° N | 123.1550° W
8723689 | Rock Harbor, Key Largo, Florida | Sub | 25.0817° N | 80.4467° W
TEC4309 | Rock Islands, Florida | Sub | 29.9667° N | 83.8333° W
8675761 | Rockdedundy River (Daymark 185), Georgia | Ref | 31.3739° N | 81.3339° W
8675761 | Rockdedundy River (Daymark 185), Georgia (sub) | Sub | 31.3739° N | 81.3339° W
8724459 | Rockland Key, Rockland Channel Bridge, Florida | Sub | 24.5917° N | 81.6700° W
8415490 | Rockland, Penobscot River, Maine | Ref | 44.1050° N | 69.1017° W
8415490 | Rockland, Penobscot River, Maine (sub) | Sub | 44.1050° N | 69.1017° W
8441551 | Rockport Harbor, Massachusetts | Ref | 42.6583° N | 70.6150° W
8441551 | Rockport Harbor, Massachusetts (sub) | Sub | 42.6583° N | 70.6150° W
8774770 | Rockport, Aransas Bay, Texas | Ref | 28.0217° N | 97.0467° W
8667089 | Rockville, Bohicket Creek, North Edisto River, South Carolina | Sub | 32.5983° N | 80.1950° W
8464255 | Rocky Hill, Connecticut River, Connecticut | Sub | 41.6633° N | 72.6300° W
TWC1115 | Rocky Point, Eld Inlet, Puget Sound, Washington | Sub | 47.0817° N | 123.0050° W
9439189 | Rocky Point, Multnomah Channel, Oregon | Ref | 45.6967° N | 122.8680° W
9454363 | Rocky Point, Valdez Arm, Alaska | Sub | 60.9467° N | 146.7550° W
ACT5146_1 | Rocky Pt. (Elk Neck), 0.25 n.mi. SW of (Depth 9ft), Chesapeake Bay, Maryland Current | Sub | 39.4883° N | 75.9975° W
8653215 | Rodanthe, Pamlico Sound, North Carolina | Sub | 35.5950° N | 75.4717° W
8770971 | Rollover Pass, Texas | Ref | 29.5156° N | 94.5106° W
TEC3403 | Romerly Marsh Creek, Georgia | Sub | 31.9333° N | 81.0000° W
TPT2691 | Rongelap Island, Rongelap Atoll, Marshall Islands | Sub | 11.1500° N | 166.9000° E
TPT2693 | Rongerik Atoll, Marshall Islands | Sub | 11.3833° N | 167.5167° E
ACT3426_1 | Roosevelt Island, east of, East River, New York Current | Sub | 40.7582° N | 73.9513° W
ACT3411_1 | Roosevelt Island, east of, off 36th Avenue, East River, New York Current | Sub | 40.7667° N | 73.9500° W
ACT3421_1 | Roosevelt Island, west of, off 63rd Street, East River, New York Current | Sub | 40.7597° N | 73.9545° W
ACT3416_1 | Roosevelt Island, west of, off 67th Street, East River, New York Current | Sub | 40.7623° N | 73.9540° W
ACT3406_1 | Roosevelt Island, west of, off 75th Street, East River, New York Current | Sub | 40.7667° N | 73.9500° W
TEC4747 | Roosevelt Roads, Puerto Rico | Sub | 18.2333° N | 65.6167° W
9462723 | Rootok Island, Rootok Strait, Alaska | Ref | 54.0522° N | 165.5142° W
9449771 | Rosario, East Sound, Orcas Island, Washington | Ref | 48.6467° N | 122.8700° W
8576256 | Rose Haven, Chesapeake Bay, Maryland | Sub | 38.7250° N | 76.5417° W
ACT2121_1 | Rose Island, northeast of (Depth 15ft), Narragansett Bay, Rhode Island Current | Sub | 41.5033° N | 71.3317° W
ACT2126_1 | Rose Island, northwest of (Depth 15ft), Narragansett Bay, Rhode Island Current | Sub | 41.5067° N | 71.3517° W
ACT2131_1 | Rose Island, west of, Narragansett Bay, Rhode Island Current | Sub | 41.4967° N | 71.3500° W
8720007 | Roses Bluff, Bells River, Florida | Sub | 30.7033° N | 81.5767° W
8519789 | Rossville, Arthur Kill, New York | Sub | 40.5567° N | 74.2233° W
TPT2627 | Rota Island, Marianas | Sub | 14.1333° N | 145.1333° E
8447842 | Round Hill Point, Buzzards Bay, Massachusetts | Ref | 41.5383° N | 70.9283° W
8447842 | Round Hill Point, Buzzards Bay, Massachusetts (sub) | Sub | 41.5383° N | 70.9283° W
TEC4185 | Round Key, Florida | Sub | 25.8333° N | 81.5333° W
8770559 | Round Point, Trinity Bay, Galveston Bay, Texas | Ref | 29.7133° N | 94.6900° W
8770559 | Round Point, Trinity Bay, Galveston Bay, Texas (sub) | Sub | 29.7133° N | 94.6900° W
8468609 | Rowayton, Fivemile River, Connecticut | Sub | 41.0650° N | 73.4450° W
8669072 | Rt. 170 bridge, New River, South Carolina | Sub | 32.2367° N | 81.0117° W
8639214 | Rudee Heights, Lake Wesley, Virginia | Sub | 36.8250° N | 75.9750° W
8639208 | Rudee Inlet entrance, Virginia | Sub | 36.8317° N | 75.9683° W
9450651 | Rudyerd Bay, Alaska | Sub | 55.6417° N | 130.6450° W
PCT3561_1 | Ruins Point, 2 miles west of, Sumner Strait, Alaska Current | Sub | 56.0667° N | 133.7500° W
8453433 | Rumford, Seekonk River, Narragansett Bay, Rhode Island | Sub | 41.8400° N | 71.3733° W
8518091 | Rye Beach (Amusement Park), New York | Ref | 40.9617° N | 73.6717° W
8518091 | Rye Beach (Amusement Park), New York (sub) | Sub | 40.9617° N | 73.6717° W
ACT7676_1 | S. Newport River, above Swain River Ent (Depth 10ft), Georgia Current | Sub | 31.6245° N | 81.2167° W
ACT7671_1 | S. Newport River, below S. Newport Cut (Depth 10ft), Georgia Current | Sub | 31.6503° N | 81.3020° W
ACT6951_1 | S.C.L. RR. bridge, 0.1 mile below, Ashley River, South Carolina Current | Sub | 32.7955° N | 79.9733° W
ACT6956_1 | S.C.L. RR. bridge, 1.5 miles above, Ashley River, South Carolina Current | Sub | 32.8200° N | 79.9650° W
8670073 | S.C.L. RR. bridge, Savannah River, Georgia | Sub | 32.2317° N | 81.1450° W
9462786 | SE Tigalda Island, Aleutian Islands, Alaska | Ref | 54.1018° N | 164.9416° W
PCT5861_1 | SW Point, St. Paul Island, 1 mile off, Pribilof Islands, Alaska Current | Sub | 57.1500° N | 170.4500° W
8771081 | Sabine (offshore), Texas | Ref | 29.4983° N | 93.6400° W
8770475 | Sabine Naches Canal, Port Arthur, Texas | Ref | 29.8671° N | 93.9310° W
8770570 | Sabine Pass (north), Texas | Ref | 29.7284° N | 93.8701° W
8770570 | Sabine Pass (north), Texas (sub) | Sub | 29.7284° N | 93.8701° W
8464687 | Sachem Head, Connecticut | Sub | 41.2450° N | 72.7083° W
8451351 | Sachuest, Flint Point, Sakonnet River, Rhode Island | Sub | 41.4867° N | 71.2383° W
9416174 | Sacramento, Sacramento River, California | Sub | 38.5800° N | 121.5070° W
8724405 | Saddlebunch Keys, Channel No. 3, Florida | Sub | 24.6233° N | 81.6033° W
8724417 | Saddlebunch Keys, Channel No. 4, Florida | Sub | 24.6150° N | 81.6167° W
8724423 | Saddlebunch Keys, Channel No. 5, Florida | Sub | 24.6117° N | 81.6233° W
8724422 | Saddlebunch Keys, Similar Sound, Florida | Sub | 24.6000° N | 81.6217° W
9455514 | Sadie Cove, Kachemak Bay, Cook Inlet, Alaska | Sub | 59.4900° N | 151.3650° W
8726738 | Safety Harbor, Old Tampa Bay, Florida | Ref | 27.9883° N | 82.6850° W
8726738 | Safety Harbor, Old Tampa Bay, Florida (sub) | Sub | 27.9883° N | 82.6850° W
8511629 | Sag Harbor, Shelter Island Sound, New York | Ref | 41.0033° N | 72.2967° W
9461667 | Sagchudak Island, Atka Island, Alaska | Sub | 52.0267° N | 174.4800° W
9451497 | Saginaw Bay, Kuiu Island, Frederick Sound, Alaska | Ref | 56.9033° N | 134.3031° W
9439201 | Saint Helens, Columbia River, Oregon | Ref | 45.8633° N | 122.7962° W
TPT2623 | Saipan Harbor, Saipan Island, Marianas | Sub | 15.2000° N | 145.7167° E
9450272 | Sakie Bay, Dall Island, Alaska | Sub | 55.0667° N | 133.2000° W
8450768 | Sakonnet, Sakonnet River, Rhode Island | Ref | 41.4650° N | 71.1933° W
8538231 | Salem Canal entrance, Delaware River, New Jersey | Sub | 39.6833° N | 75.5100° W
8442645 | Salem, Salem Harbor, Massachusetts | Ref | 42.5233° N | 70.8767° W
8442645 | Salem, Salem Harbor, Massachusetts (sub) | Sub | 42.5233° N | 70.8767° W
8537979 | Salem, Salem River, New Jersey | Sub | 39.5767° N | 75.4767° W
8440273 | Salisbury Point, Merrimack River, Massachusetts | Ref | 42.8383° N | 70.9083° W
8440273 | Salisbury Point, Merrimack River, Massachusetts (sub) | Sub | 42.8383° N | 70.9083° W
8571616 | Salisbury, Wicomico River, Maryland | Ref | 38.3650° N | 75.6067° W
8419997 | Salmon Falls River, Piscataqua River, New Hampshire | Sub | 43.1917° N | 70.8250° W
9450495 | Saltery Cove, Skowl Arm, Kasaan Bay, Alaska | Sub | 55.4017° N | 132.3280° W
9450351 | Saltery Point, Tlevak Strait, Alaska | Sub | 55.1817° N | 132.7950° W
9418817 | Samoa, Humboldt Bay, California | Ref | 40.8267° N | 124.1800° W
ACT6556_1 | Sampit River entrance, Winyah Bay, South Carolina Current | Sub | 33.3513° N | 79.2803° W
ACT7076_1 | Sampson Island, NE end, South Edisto River (Depth 15ft), South Carolina Current | Sub | 32.6167° N | 80.3867° W
ACT7071_1 | Sampson Island, S end, South Edisto River (Depth 15ft), South Carolina Current | Sub | 32.5633° N | 80.3917° W
8667733 | Sams Point, Lucy Point Creek, Coosaw River, South Carolina | Sub | 32.4833° N | 80.6000° W
ACT7161_1 | Sams Point, Northwest of, Coosaw River (Depth 10ft), South Carolina Current | Sub | 32.4933° N | 80.5933° W
TWC0419 | San Clemente, California | Sub | 33.4167° N | 117.6167° W
PCT0031_1 | San Diego Bay Entrance, California Current | Ref | 32.6817° N | 117.2300° W
PCT0066_1 | San Diego, 0.5 mile west of, San Diego Bay, California Current | Sub | 32.7167° N | 117.1833° W
9410166 | San Diego, Quarantine Station, California | Sub | 32.7033° N | 117.2350° W
9410170 | San Diego, San Diego Bay, California | Ref | 32.7142° N | 117.1736° W
TWC0509 | San Francisco Bar, California | Sub | 37.7667° N | 122.6333° W
9414290 | San Francisco, San Francisco Bay, California | Ref | 37.8063° N | 122.4659° W
8770743 | San Jacinto Battleground State Historic Site, Texas | Ref | 29.7567° N | 95.0900° W
9755371 | San Juan, La Puntilla, San Juan Bay, Puerto Rico | Ref | 18.4592° N | 66.1164° W
9414724 | San Leandro Channel, San Leandro Bay, San Francisco Bay, California | Sub | 37.7483° N | 122.2350° W
9414688 | San Leandro Marina, San Francisco Bay, California | Ref | 37.6950° N | 122.1920° W
9414688 | San Leandro Marina, San Francisco Bay, California (sub) | Sub | 37.6950° N | 122.1920° W
8771972 | San Luis Pass (TCOON), Texas | Ref | 29.0810° N | 95.1313° W
8723156 | San Marino Island, Biscayne Bay, Florida | Sub | 25.7933° N | 80.1633° W
9414637 | San Mateo Bridge (east end), San Francisco Bay, California | Sub | 37.6083° N | 122.1820° W
9414458 | San Mateo Bridge (west end), San Francisco Bay, California | Ref | 37.5800° N | 122.2530° W
9414458 | San Mateo Bridge (west end), San Francisco Bay, California (sub) | Sub | 37.5800° N | 122.2530° W
9410068 | San Nicolas Island, California | Sub | 33.2667° N | 119.4970° W
9412553 | San Simeon, California | Sub | 35.6417° N | 121.1880° W
9459968 | Sanak Harbor, Sanak Islands, Alaska | Sub | 54.4817° N | 162.8120° W
9459311 | Sanborn Harbor, Nagai Island, Shumagin Islands, Alaska | Sub | 55.1550° N | 159.9950° W
9461453 | Sand Bay, Great Sitkin Island, Aleutian Islands, Alaska | Sub | 51.9733° N | 176.0850° W
PCT1111_1 | Sand Island Tower, 0.9nm SE of (north channel) (Depth 15ft), Washington Current | Sub | 46.2578° N | 123.9945° W
PCT1106_1 | Sand Island Tower, 1nm SE of (midchannel) (Depth 15ft), Washington Current | Sub | 46.2528° N | 123.9908° W
1619910 | Sand Island, Midway Islands | Ref | 28.2117° N | 177.3600° W
PCT1126_1 | Sand Island, SSE of (Depth 12ft), Washington Current | Sub | 46.2555° N | 123.9680° W
8724635 | Sand Key Lighthouse, Sand Key Channel, Florida | Ref | 24.4533° N | 81.8783° W
8724635 | Sand Key Lighthouse, Sand Key Channel, Florida (sub) | Sub | 24.4533° N | 81.8783° W
9459450 | Sand Point, Popof Island, Alaska | Ref | 55.3367° N | 160.5020° W
8631542 | Sand Shoal Inlet (Coast Guard Station), Virginia | Sub | 37.3017° N | 75.7783° W
8665589 | Sandblasters, Pennys Creek, Stono River, South Carolina | Sub | 32.7700° N | 80.0633° W
8639428 | Sandbridge, Virginia | Sub | 36.6917° N | 75.9200° W
8723372 | Sands Key, northwest point, Biscayne Bay, Florida | Sub | 25.5067° N | 80.1883° W
8531680 | Sandy Hook, New Jersey | Ref | 40.4669° N | 74.0094° W
ACT5941_1 | Sandy Point, 0.5 mile south of, Patuxent River, Maryland Current | Sub | 38.3083° N | 76.4550° W
ACT4991_1 | Sandy Point, 0.8 n.mi. ESE of (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 39.0040° N | 76.3800° W
ACT4991_2 | Sandy Point, 0.8 n.mi. ESE of (Depth 43ft), Chesapeake Bay, Maryland Current | Sub | 39.0040° N | 76.3800° W
ACT4986_1 | Sandy Point, 2.3 n.mi. east of (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 39.0027° N | 76.3488° W
ACT4986_2 | Sandy Point, 2.3 n.mi. east of (Depth 41ft), Chesapeake Bay, Maryland Current | Sub | 39.0027° N | 76.3488° W
9446804 | Sandy Point, Anderson Island, Puget Sound, Washington | Ref | 47.1530° N | 122.6751° W
8459479 | Sandy Point, Block Island Sound, Rhode Island | Ref | 41.2283° N | 71.5800° W
9449292 | Sandy Point, Lummi Bay, Washington | Sub | 48.7900° N | 122.7080° W
8414692 | Sandy Point, Penobscot River, Maine | Sub | 44.5050° N | 68.8050° W
9447856 | Sandy Point, Whidbey Island, Washington | Sub | 48.0350° N | 122.3770° W
9410599 | Santa Ana River entrance (inside), California | Sub | 33.6300° N | 117.9580° W
TWC0463 | Santa Barbara Island, California | Sub | 33.4833° N | 119.0333° W
9411340 | Santa Barbara, California | Ref | 34.4031° N | 119.6928° W
9411340 | Santa Barbara, California (sub) | Sub | 34.4031° N | 119.6928° W
9413745 | Santa Cruz, Monterey Bay, California | Sub | 36.9583° N | 122.0170° W
9756639 | Santa Isabel, Puerto Rico | Ref | 17.9550° N | 66.4067° W
9410840 | Santa Monica, Municipal Pier, San Pedro Channel, California | Ref | 34.0083° N | 118.5000° W
9410840 | Santa Monica, Municipal Pier, San Pedro Channel, California (sub) | Sub | 34.0083° N | 118.5000° W
ACT7696_1 | Sapelo River Entrance (Depth 11ft), Sapelo Sound, Georgia Current | Sub | 31.5350° N | 81.2717° W
8447495 | Saquatucket Harbor, Nantucket Sound, Massachusetts | Ref | 41.6683° N | 70.0567° W
8447495 | Saquatucket Harbor, Nantucket Sound, Massachusetts (sub) | Sub | 41.6683° N | 70.0567° W
ACT8376_1 | Sarasota Bay, south end, bridge, Sarasota Bay, Florida Current | Sub | 27.3017° N | 82.5467° W
8726083 | Sarasota, Sarasota Bay, Florida | Sub | 27.3317° N | 82.5450° W
8772985 | Sargent (TCOON), Texas | Ref | 28.7714° N | 95.6172° W
8573704 | Sassafras River, Betterton, Chesapeake Bay, Maryland | Ref | 39.3717° N | 76.0633° W
8573704 | Sassafras River, Betterton, Chesapeake Bay, Maryland (sub) | Sub | 39.3717° N | 76.0633° W
TPT2667 | Satawan Anchorage, Nomoi Islands, Chuuk, FSM | Sub | 5.3333° N | 153.7333° E
8468191 | Saugatuck, Saugatuck River, Long Island Sound, Connecticut | Ref | 41.1200° N | 73.3683° W
8635554 | Saunders Wharf, Rappahannock River, Virginia | Sub | 38.0900° N | 77.0333° W
9414819 | Sausalito, Corps of Engineers Dock, San Francisco Bay, California | Ref | 37.8650° N | 122.4930° W
9414819 | Sausalito, Corps of Engineers Dock, San Francisco Bay, California (sub) | Sub | 37.8650° N | 122.4930° W
9414806 | Sausalito, San Francisco Bay, California | Ref | 37.8467° N | 122.4770° W
9414806 | Sausalito, San Francisco Bay, California (sub) | Sub | 37.8467° N | 122.4770° W
8669323 | Savage I., Savage Creek, Bull Creek, South Carolina | Sub | 32.1850° N | 80.8600° W
8670681 | Savannah (Bull Street), Georgia | Ref | 32.0817° N | 81.0917° W
8670681 | Savannah (Bull Street), Georgia (sub) | Sub | 32.0817° N | 81.0917° W
ACT7351_1 | Savannah River Entrance (between jetties), Georgia Current (11d) | Ref | 32.0357° N | 80.8903° W
TEC3405 | Savannah Sheraton Resort Hotel, Wilmington River, Georgia | Sub | 32.0000° N | 81.0000° W
ACT7411_1 | Savannah, Savannah River, Georgia Current | Sub | 32.0833° N | 81.0833° W
ACT7406_1 | Savannah, southeast of highway bridge (Depth 10ft), Savannah River, Georgia Current | Sub | 32.0867° N | 81.0967° W
9468258 | Savoonga, St. Lawrence Island, Alaska | Ref | 63.6791° N | 170.5371° W
9454764 | Sawmill Bay, Evans Island, Prince William Sound, Alaska | Sub | 60.0517° N | 148.0650° W
8720137 | Sawpit Creek entrance, bridge, Florida | Sub | 30.5133° N | 81.4567° W
8720143 | Sawpit Creek, 1 mi. above entrance, Florida | Sub | 30.5033° N | 81.4717° W
9452022 | Sawyer Island, Tracy Arm, Alaska | Sub | 57.8783° N | 133.1900° W
8724369 | Sawyer Key, inside, Cudjoe Channel, Florida | Sub | 24.7583° N | 81.5617° W
8724370 | Sawyer Key, outside, Cudjoe Channel, Florida | Sub | 24.7583° N | 81.5617° W
8573777 | Saxis, Starling Creek, Pocomoke Sound, Chesapeake Bay, Maryland | Sub | 37.9217° N | 75.7283° W
8633777 | Saxis, Starling Creek, Virginia | Ref | 37.9217° N | 75.7283° W
PCT2781_1 | Saxman Spire, 0.2 mile south of, Tongass Narrows, Alaska Current | Sub | 55.3155° N | 131.6027° W
8462723 | Saybrook Jetty, Connecticut River, Connecticut | Sub | 41.2633° N | 72.3433° W
8462752 | Saybrook Point, Connecticut River, Connecticut | Sub | 41.2833° N | 72.3500° W
8531390 | Sayreville, Raritan River, New Jersey | Ref | 40.4783° N | 74.3567° W
8445138 | Scituate, Scituate Harbor, Massachusetts | Ref | 42.2017° N | 70.7267° W
8445138 | Scituate, Scituate Harbor, Massachusetts (sub) | Sub | 42.2017° N | 70.7267° W
9462808 | Scotch Cap, Unimak Island, Alaska | Ref | 54.3936° N | 164.7457° W
9462808 | Scotch Cap, Unimak Island, Alaska (sub) | Sub | 54.3936° N | 164.7457° W
8638433 | Scotland, James River, Virginia | Ref | 37.1850° N | 76.7833° W
8638433 | Scotland, James River, Virginia (sub) | Sub | 37.1850° N | 76.7833° W
9451805 | Scraggy Island, Alaska | Ref | 57.3400° N | 135.7070° W
9451805 | Scraggy Island, Alaska (sub) | Sub | 57.3400° N | 135.7070° W
9451802 | Scraggy Point, Alaska | Sub | 57.3367° N | 135.7230° W
8531804 | Sea Bright, Shrewsbury River, New Jersey | Ref | 40.3650° N | 73.9750° W
8531804 | Sea Bright, Shrewsbury River, New Jersey (sub) | Sub | 40.3650° N | 73.9750° W
8723393 | Sea Grape Point, Elliott Key, Florida | Sub | 25.4767° N | 80.1800° W
8655875 | Sea Level, Core Sound, North Carolina | Ref | 34.8750° N | 76.3433° W
9450312 | Sea Otter Harbor, Dall Island, Alaska | Sub | 55.1267° N | 133.1670° W
PCT4236_1 | Sea Rock, 1 mile north of, Salisbury Sound, Alaska Current | Sub | 57.3500° N | 135.8833° W
9445303 | Seabeck, Seabeck Bay, Washington | Sub | 47.6417° N | 122.8280° W
ACT7421_1 | Seaboard Coast Line Railroad, Savannah River, Georgia Current | Sub | 32.1033° N | 81.1183° W
8667524 | Seabrook, Ashepoo River, South Carolina | Sub | 32.5233° N | 80.4067° W
8773037 | Seadrift, San Antonio Bay, Texas | Ref | 28.4069° N | 96.7124° W
9457201 | Seal Bay, Alaska | Sub | 58.3717° N | 152.2380° W
9459643 | Seal Cape, Coal Bay, Alaska | Sub | 55.3650° N | 161.3250° W
9454564 | Seal Island, Alaska | Ref | 60.4250° N | 147.4100° W
9414413 | Seaplane Harbor, San Francisco Bay, California | Sub | 37.6367° N | 122.3830° W
8419590 | Seapoint, Cutts Island, Maine | Sub | 43.0850° N | 70.6617° W
8533071 | Seaside Heights, ocean, New Jersey | Sub | 39.9433° N | 74.0350° W
8533135 | Seaside Park, Barnegat Bay, New Jersey | Sub | 39.9217° N | 74.0833° W
9447130 | Seattle, Puget Sound, Washington | Ref | 47.6026° N | 122.3393° W
8419870 | Seavey Island, Portsmouth Harbor, New Hampshire | Ref | 43.0800° N | 70.7417° W
8419870 | Seavey Island, Portsmouth Harbor, New Hampshire (sub) | Sub | 43.0800° N | 70.7417° W
8514779 | Seaview Ferry Dock, Great South Bay, New York | Ref | 40.6493° N | 73.1506° W
8722004 | Sebastian Inlet bridge, Florida | Sub | 27.8600° N | 80.4483° W
8722029 | Sebastian, Indian River, Florida | Sub | 27.8117° N | 80.4633° W
9450055 | Security Cove, Dall Island, Alaska | Sub | 54.7483° N | 132.8550° W
9443361 | Sekiu, Clallam Bay, Strait of Juan de Fuca, Washington | Ref | 48.2633° N | 124.2970° W
9415142 | Selby, California | Sub | 38.0583° N | 122.2430° W
9455500 | Seldovia, Cook Inlet, Alaska | Ref | 59.4405° N | 151.7199° W
8722366 | Seminole Shores, Florida | Sub | 27.1833° N | 80.1583° W
9444555 | Sequim Bay entrance, Strait of Juan de Fuca, Washington | Sub | 48.0817° N | 123.0430° W
9451853 | Sergius Narrows, Alaska | Ref | 57.4100° N | 135.6270° W
9451853 | Sergius Narrows, Alaska (sub) | Sub | 57.4100° N | 135.6270° W
8447241 | Sesuit Harbor, East Dennis, Cape Cod Bay, Massachusetts | Ref | 41.7517° N | 70.1550° W
8447241 | Sesuit Harbor, East Dennis, Cape Cod Bay, Massachusetts (sub) | Sub | 41.7517° N | 70.1550° W
9463195 | Settlement Point, Pavlof Bay, Alaska | Sub | 55.5000° N | 161.4667° W
9439054 | Settlers Point, Oregon | Sub | 46.1750° N | 123.6780° W
8534296 | Seven Island, Newmans Thorofare, Great Bay, New Jersey | Sub | 39.5167° N | 74.3367° W
8722371 | Sewall Point, St. Lucie River, Florida | Sub | 27.1750° N | 80.1883° W
9455090 | Seward, Resurrection Bay, Alaska | Ref | 60.1200° N | 149.4267° W
9455090 | Seward, Resurrection Bay, Alaska (sub) | Sub | 60.1200° N | 149.4267° W
8638610 | Sewells Point, Hampton Roads, Virginia | Ref | 36.9467° N | 76.3300° W
ACT6326_1 | Shackleford Banks, 0.8 mile S of (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.6663° N | 76.6555° W
ACT6396_1 | Shackleford Point, NE of (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.6922° N | 76.6522° W
9454125 | Shag Rock, Orca Inlet, Alaska | Sub | 60.4650° N | 145.9880° W
9450982 | Shakan Bay Entrance, Alaska | Sub | 56.1400° N | 133.6100° W
PCT3576_1 | Shakan Light, 2.8 miles WNW of, Sumner Strait, Alaska Current | Sub | 56.1667° N | 133.7000° W
9450987 | Shakan Strait, Kosciusko Island, Alaska | Sub | 56.1483° N | 133.4600° W
9468691 | Shaktoolik, Alaska | Ref | 64.3802° N | 161.2351° W
8729538 | Shalimar, Garnier Bayou, Choctawhatchee Bay, Florida | Sub | 30.4350° N | 86.5867° W
8659665 | Shallotte Inlet (Bowen Point), North Carolina | Sub | 33.9150° N | 78.3733° W
8724438 | Shark Key, southeast end, Similar Sound, Florida | Sub | 24.6033° N | 81.6450° W
8532322 | Shark River Hills, Shark River, New Jersey | Sub | 40.1917° N | 74.0383° W
8532339 | Shark River Island, fixed RR. bridge, Shark River, New Jersey | Sub | 40.1867° N | 74.0267° W
8724769 | Shark River entrance, Florida | Sub | 25.3450° N | 81.1267° W
8571396 | Sharkfin Shoal Light, Chesapeake Bay, Maryland | Sub | 38.2017° N | 75.9867° W
ACT4911_1 | Sharp Island Lt., 2.1 n.mi. west of (Depth 18ft), Chesapeake Bay, Maryland Current | Sub | 38.6433° N | 76.4203° W
ACT4906_1 | Sharp Island Lt., 2.3 n.mi. SE of (Depth 20ft), Chesapeake Bay, Maryland Current | Sub | 38.6072° N | 76.3480° W
ACT4916_1 | Sharp Island Lt., 3.4 n.mi. west of (Depth 18ft), Chesapeake Bay, Maryland Current | Sub | 38.6438° N | 76.4480° W
ACT4916_2 | Sharp Island Lt., 3.4 n.mi. west of (Depth 35ft), Chesapeake Bay, Maryland Current | Sub | 38.6438° N | 76.4480° W
8571858 | Sharptown, Nanticoke River, Maryland | Sub | 38.5450° N | 75.7233° W
9449904 | Shaw Island, Ferry Terminal, Harney Channel, San Juan Channel, Washington | Sub | 48.5850° N | 122.9280° W
ACT6316_1 | Sheep Island Slue, Pamlico Sound, North Carolina Current | Sub | 35.0667° N | 76.1000° W
8416804 | Sheepscot (below rapids), Sheepscot River, Maine | Sub | 44.0500° N | 69.6183° W
8667172 | Sheldon, Huspa Creek, Whale Branch, Coosaw River, South Carolina | Sub | 32.5833° N | 80.7833° W
8761305 | Shell Beach, Lake Borgne, Louisiana | Ref | 29.8681° N | 89.6732° W
8761305 | Shell Beach, Lake Borgne, Louisiana (sub) | Sub | 29.8681° N | 89.6732° W
8764165 | Shell Island, Atchafalaya Bay, Louisiana | Sub | 29.4733° N | 91.3050° W
8727359 | Shell Island, north end, Crystal River, Florida | Ref | 28.9233° N | 82.6917° W
8727359 | Shell Island, north end, Crystal River, Florida (sub) | Sub | 28.9233° N | 82.6917° W
8723812 | Shell Key Channel, Florida Bay, Florida | Sub | 24.9133° N | 80.6600° W
8723807 | Shell Key, northwest side, Lignumvitae Basin, Florida | Sub | 24.9233° N | 80.6717° W
8726468 | Shell Point, Florida | Sub | 27.7183° N | 82.4800° W
TEC2801 | Shell Point, Harkers Island, North Carolina | Sub | 34.6833° N | 76.5333° W
8728229 | Shell Point, Walker Creek, Apalachee Bay, Florida | Ref | 30.0600° N | 84.2900° W
8728229 | Shell Point, Walker Creek, Apalachee Bay, Florida (sub) | Sub | 30.0600° N | 84.2900° W
8571097 | Shelltown, Pocomoke River, Maryland | Sub | 37.9800° N | 75.6383° W
9418024 | Shelter Cove, California | Ref | 40.0250° N | 124.0580° W
8466573 | Shelton, Housatonic River, Connecticut | Sub | 41.3017° N | 73.0717° W
9446628 | Shelton, Oakland Bay, Puget Sound, Washington | Sub | 47.2150° N | 123.0830° W
8665426 | Shem Creek, South Carolina | Sub | 32.7933° N | 79.8817° W
ACT5956_1 | Sheridan Point, 0.1 mile southwest of, Patuxent River, Maryland Current | Sub | 38.4662° N | 76.6480° W
8720213 | Sherwood Forest, Trout River, Florida | Ref | 30.4200° N | 81.7283° W
8720213 | Sherwood Forest, Trout River, Florida (sub) | Sub | 30.4200° N | 81.7283° W
8729747 | Shield Point, Blackwater River, Florida | Ref | 30.5817° N | 87.0150° W
8512671 | Shinnecock Bay entrance, Shinnecock Bay, New York | Sub | 40.8200° N | 72.5617° W
8512354 | Shinnecock Inlet (ocean), Long Island, New York | Ref | 40.8367° N | 72.4800° W
8512769 | Shinnecock Yacht Club, Penniman Creek, Shinnecock Bay, New York | Ref | 40.8186° N | 72.5866° W
8512769 | Shinnecock Yacht Club, Penniman Creek, Shinnecock Bay, New York (sub) | Sub | 40.8186° N | 72.5866° W
9448772 | Ship Harbor, Fidalgo Island, Washington | Sub | 48.5067° N | 122.6770° W
PCT3021_1 | Ship Island, Clarence Strait, Alaska Current | Sub | 55.6000° N | 132.2500° W
8744756 | Ship Island, Mississippi Sound, Mississippi | Ref | 30.2133° N | 88.9717° W
8744756 | Ship Island, Mississippi Sound, Mississippi (sub) | Sub | 30.2133° N | 88.9717° W
8537121 | Ship John Shoal, Delaware River, New Jersey | Ref | 39.3050° N | 75.3750° W
8763719 | Ship Shoal Light, Louisiana | Sub | 28.9150° N | 91.0717° W
ACT6786_1 | Shipyard Creek entrance, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.8300° N | 79.9350° W
TEC3061 | Shipyard Creek, 0.8 mile above entrance., South Carolina | Sub | 32.8333° N | 79.9500° W
8444788 | Shipyard Point, Weymouth Fore River, Massachusetts | Ref | 42.2483° N | 70.9667° W
8444788 | Shipyard Point, Weymouth Fore River, Massachusetts (sub) | Sub | 42.2483° N | 70.9667° W
9469854 | Shishmaref Inlet 2, Alaska | Ref | 66.2633° N | 166.0200° W
9461292 | Shoal Point, Kanaga Island, Alaska | Sub | 51.8700° N | 177.0680° W
PCT3231_1 | Shoe Rock, 1 mile north of, Tlevak Strait, Alaska Current | Sub | 54.9667° N | 132.7333° W
8534319 | Shooting Thorofare, Little Egg Inlet, Great Bay, New Jersey | Ref | 39.5083° N | 74.3250° W
8411696 | Shoppee Point, Englishman Bay, Maine | Sub | 44.6150° N | 67.4967° W
ACT6691_1 | Shutes Folly Island, 0.4 mile west of, Charleston Harbor, South Carolina Current | Sub | 32.7763° N | 79.9208° W
ACT6741_1 | Shutes Reach, Buoy '8', Charleston Harbor, South Carolina Current | Sub | 32.7822° N | 79.9108° W
8724542 | Sigsbee Park, Garrison Bight Channel, Florida | Sub | 24.5850° N | 81.7750° W
8532921 | Silver Bay, Silver Bay Marina, Barnegat Bay, New Jersey | Sub | 39.9967° N | 74.1483° W
8510719 | Silver Eel Pond, Fishers Island, New York | Ref | 41.2567° N | 72.0300° W
8510719 | Silver Eel Pond, Fishers Island, New York (sub) | Sub | 41.2567° N | 72.0300° W
8720168 | Simpson Creek, A1A highway bridge, Florida | Sub | 30.4650° N | 81.4317° W
PCT4246_1 | Sinitsin Island, Salisbury Sound, Alaska Current | Sub | 57.3500° N | 135.7667° W
8537961 | Sinnickson Landing, Salem River, New Jersey | Sub | 39.5700° N | 75.4983° W
ACT7991_2 | Sisters Creek entrance (bridge) (Depth 10ft), St. Johns River, Florida Current | Sub | 30.3900° N | 81.4617° W
ACT7991_1 | Sisters Creek entrance (bridge) (Depth 4ft), St. Johns River, Florida Current | Sub | 30.3900° N | 81.4617° W
8720196 | Sisters Creek, Florida | Ref | 30.4167° N | 81.4533° W
8720196 | Sisters Creek, Florida (sub) | Sub | 30.4167° N | 81.4533° W
9432879 | Sitka Dock, Coos Bay, Oregon | Sub | 43.3767° N | 124.2970° W
PCT4166_1 | Sitka Harbor, channel off Harbor Island, Sitka Sound, Alaska Current | Sub | 57.0500° N | 135.3333° W
9451600 | Sitka, Baronof Island, Sitka Sound, Alaska | Ref | 57.0517° N | 135.3420° W
9457512 | Sitkalidak Island GPS Tide Buoy, Alaska | Ref | 56.9657° N | 153.2522° W
TWC2051 | Sitkinak Lagoon, Alaska | Sub | 56.5000° N | 154.1333° W
9434132 | Siuslaw River entrance, Oregon | Sub | 44.0167° N | 124.1300° W
PCT1941_1 | Skagit Bay, 1 mi. S of Goat Island, Washington Current | Sub | 48.3445° N | 122.5437° W
9452400 | Skagway, Taiya Inlet, Lynn Canal, Alaska | Ref | 59.4500° N | 135.3270° W
9452400 | Skagway, Taiya Inlet, Lynn Canal, Alaska (sub) | Sub | 59.4500° N | 135.3270° W
9440569 | Skamokawa, Steamboat Slough, Columbia River, Washington | Ref | 46.2667° N | 123.4520° W
9462554 | Skan Bay, Unalaska Island, Alaska | Sub | 53.6100° N | 167.0450° W
8671086 | Skidaway Institute, Skidaway River, Georgia | Ref | 31.9900° N | 81.0233° W
ACT7501_1 | Skidaway Island, N End, Wilmington River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 32.0100° N | 81.0083° W
ACT7526_1 | Skidaway Narrows, Wassaw Sound, Georgia Current | Sub | 31.9533° N | 81.0650° W
ACT7496_1 | Skidaway River, north entrance, Wassaw Sound, Georgia Current | Sub | 32.0083° N | 81.0167° W
PCT2991_1 | Skin Island, 3 miles east from, Clarence Strait, Alaska Current | Sub | 55.3000° N | 131.9833° W
PCT3476_1 | Skookumchuck Pass, El Capitan Passage, Alaska Current | Sub | 55.9147° N | 133.3123° W
8668918 | Skull Creek, Ribaut Island, South Carolina | Ref | 32.2667° N | 80.7367° W
8668918 | Skull Creek, Ribaut Island, South Carolina (sub) | Sub | 32.2667° N | 80.7367° W
ACT7246_1 | Skull Creek, north entrance, Port Royal Sound, South Carolina Current | Sub | 32.2633° N | 80.7417° W
ACT7306_1 | Skull Creek, south entrance (Depth 10ft), Calibogue Sound, South Carolina Current | Sub | 32.2233° N | 80.7850° W
8669133 | Skull Creek, south entrance, Hilton Head Island, South Carolina | Sub | 32.2233° N | 80.7717° W
8533185 | Sloop Creek, Barnegat Bay, New Jersey | Sub | 39.9050° N | 74.1333° W
8536687 | Sluice Creek, Route 47 bridge, Dennis Creek, Delaware Bay, New Jersey | Sub | 39.1617° N | 74.8317° W
8720833 | Smith Creek, Flagler Beach, Florida | Sub | 29.4783° N | 81.1367° W
8631874 | Smith Island (Coast Guard Station), Virginia | Sub | 37.1233° N | 75.9117° W
TWC1907 | Smith Island, Prince William Sound, Alaska | Sub | 60.5333° N | 147.3167° W
9447985 | Smith Island, Strait of Juan de Fuca, Washington | Sub | 48.3167° N | 122.8370° W
8513825 | Smith Point Bridge, Narrow Bay, Long Island, New York | Ref | 40.7383° N | 72.8683° W
8513825 | Smith Point Bridge, Narrow Bay, Long Island, New York (sub) | Sub | 40.7383° N | 72.8683° W
8724671 | Smith Shoal Light, Florida | Ref | 24.7183° N | 81.9215° W
9414511 | Smith Slough, San Francisco Bay, California | Sub | 37.5017° N | 122.2230° W
8661559 | Smith's Dock, Murrells Inlet, South Carolina | Sub | 33.5450° N | 79.0450° W
8638418 | Smithfield, Pagan River, James River, Virginia | Sub | 36.9833° N | 76.6300° W
8571702 | Smithville Road Bridge, Beaverdam Creek, Little Choptank River, Maryland | Ref | 38.4283° N | 76.2367° W
8571702 | Smithville Road Bridge, Beaverdam Creek, Little Choptank River, Maryland (sub) | Sub | 38.4283° N | 76.2367° W
ACT7086_1 | Smuggedy Swamp, South Edisto River (Depth 6ft), South Carolina Current | Sub | 32.6600° N | 80.4117° W
TPT2803 | Smuggler Cove, Kahoolawe Island, Hawaii | Sub | 20.5167° N | 156.6833° W
9465374 | Snag Point, Dillingham, Alaska | Ref | 59.0400° N | 158.4470° W
9465374 | Snag Point, Dillingham, Alaska (sub) | Sub | 59.0400° N | 158.4470° W
8723787 | Snake Creek, Hwy. 1 bridge, Windley Key, Florida | Sub | 24.9517° N | 80.5883° W
8723786 | Snake Creek, USCG Station, Plantation Key, Florida | Sub | 24.9533° N | 80.5867° W
ACT6981_1 | Snake Island (Depth 12ft), Stono River, South Carolina Current | Sub | 32.6400° N | 80.0200° W
8666767 | Snake Island, Stono River, South Carolina | Sub | 32.6400° N | 80.0150° W
9448576 | Sneeoosh Point, Washington | Ref | 48.4000° N | 122.5480° W
8466791 | Sniffens Point, Housatonic River, Connecticut | Sub | 41.1867° N | 73.1133° W
PCT2831_1 | Snipe Island, Felice Strait, Alaska Current | Sub | 55.0000° N | 131.3833° W
8724427 | Snipe Keys, Middle Narrows, Florida | Sub | 24.6667° N | 81.6300° W
8724463 | Snipe Keys, Snipe Point, Florida | Sub | 24.6917° N | 81.6733° W
8724409 | Snipe Keys, southeast end, Inner Narrows, Florida | Sub | 24.6583° N | 81.6083° W
9415565 | Snodgrass Slough, Sacramento River, California | Sub | 38.2767° N | 121.4950° W
8571359 | Snow Hill, city park, Pocomoke River, Maryland | Ref | 38.1783° N | 75.3967° W
8571359 | Snow Hill, city park, Pocomoke River, Maryland (sub) | Sub | 38.1783° N | 75.3967° W
8664515 | Snow Point, 0.4 mi. North of, Cooper River, South Carolina | Sub | 32.9483° N | 79.9317° W
ACT6851_1 | Snow Point, 0.5 mile north of, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.9517° N | 79.9300° W
TWC1909 | Snug Corner Cove, Port Fidalgo, Prince William Sound, Alaska | Sub | 60.7333° N | 146.6500° W
9456173 | Snug Harbor, Cook Inlet, Alaska | Sub | 60.1075° N | 152.5817° W
9454662 | Snug Harbor, Knight Island, Alaska | Ref | 60.2500° N | 147.7170° W
9454662 | Snug Harbor, Knight Island, Alaska (sub) | Sub | 60.2500° N | 147.7170° W
8660983 | Socastee Bridge, South Carolina | Sub | 33.6867° N | 79.0050° W
9450413 | Soda Bay, Tlevak Strait, Alaska | Sub | 55.2750° N | 132.9670° W
8723303 | Soldier Key, Florida | Sub | 25.5900° N | 80.1617° W
8577330 | Solomons Island, Patuxent River, Maryland | Ref | 38.3172° N | 76.4508° W
8577330 | Solomons Island, Patuxent River, Maryland (sub) | Sub | 38.3172° N | 76.4508° W
8723999 | Sombrero Key, Hawk Channel, Florida | Sub | 24.6267° N | 81.1117° W
9415338 | Sonoma Creek, San Pablo Bay, California | Ref | 38.1567° N | 122.4070° W
8531232 | South Amboy, Raritan River, New Jersey | Sub | 40.4917° N | 74.2817° W
9454652 | South Arm, Knight Island, Bay of Isles, Alaska | Ref | 60.3667° N | 147.7000° W
8665495 | South Ashley Bridge, Ashley River, South Carolina | Sub | 32.7833° N | 79.9567° W
9414609 | South Bay Wreck, San Francisco Bay, California | Sub | 37.5517° N | 122.1620° W
8779768 | South Bay entrance, Texas | Sub | 26.0517° N | 97.1817° W
9454721 | South Bay, Perry Island, Alaska | Ref | 60.6717° N | 147.9320° W
8722219 | South Beach Causeway, Indian River, Florida | Ref | 27.4567° N | 80.3233° W
9435380 | South Beach, Yaquina Bay and River, Oregon | Ref | 44.6250° N | 124.0430° W
9435380 | South Beach, Yaquina Bay and River, Oregon (sub) | Sub | 44.6250° N | 124.0430° W
PCT1271_1 | South Bend, Willapa River, Washington Current | Sub | 46.6647° N | 123.8013° W
9440875 | South Bend, Willapa River, Willapa Bay, Washington | Ref | 46.6633° N | 123.7980° W
9440875 | South Bend, Willapa River, Willapa Bay, Washington (sub) | Sub | 46.6633° N | 123.7980° W
ACT3381_1 | South Brother Island, NW of (Depth 15ft), East River, New York Current | Sub | 40.7967° N | 73.9017° W
8728488 | South Carrabelle Beach, Florida | Ref | 29.8017° N | 84.7367° W
ACT6666_1 | South Chan., 0.4 mi. NW of Ft. Johnson, Charleston Harbor, South Carolina Current | Sub | 32.7580° N | 79.9063° W
ACT6661_1 | South Chan., 0.8 mi. ENE of Ft. Johnson, Charleston Harbor, South Carolina Current | Sub | 32.7587° N | 79.8847° W
ACT6681_1 | South Channel, Buoy '32', Charleston Harbor, South Carolina Current | Sub | 32.7622° N | 79.9110° W
ACT7396_1 | South Channel, western end, Savannah River, Georgia Current | Sub | 32.0883° N | 81.0167° W
8722761 | South Delray Beach, ICWW, Florida | Ref | 26.4467° N | 80.0650° W
8665111 | South Dewees Island, Dewees Inlet, South Carolina | Sub | 32.8333° N | 79.7267° W
ACT7056_1 | South Edisto River entrance, South Carolina Current | Sub | 32.4883° N | 80.3483° W
8722376 | South Fork, St. Lucie River, Florida | Sub | 27.1650° N | 80.2550° W
8417801 | South Freeport, Casco Bay, Maine | Sub | 43.8200° N | 70.1033° W
8417647 | South Harpswell, Potts Harbor, Casco Bay, Maine | Sub | 43.7383° N | 70.0233° W
8464418 | South Hartford, Connecticut River, Connecticut | Sub | 41.7550° N | 72.6583° W
8662549 | South Island Ferry, Intracoastal Waterway, South Carolina | Sub | 33.2517° N | 79.2683° W
8662746 | South Island Plantation (C.G. Station), Winyah Bay, South Carolina | Ref | 33.2350° N | 79.2033° W
8662746 | South Island Plantation (C.G. Station), Winyah Bay, South Carolina (sub) | Sub | 33.2350° N | 79.2033° W
8512735 | South Jamesport, Great Peconic Bay, New York | Ref | 40.9350° N | 72.5817° W
8512735 | South Jamesport, Great Peconic Bay, New York (sub) | Sub | 40.9350° N | 72.5817° W
ACT6646_1 | South Jetty, break in, Charleston Harbor, South Carolina Current | Sub | 32.7312° N | 79.8503° W
TEC3447 | South Newport Cut, N. Newport River, Georgia | Sub | 31.6667° N | 81.2667° W
8674301 | South Newport River (Daymark 135), Georgia | Ref | 31.5750° N | 81.1900° W
8674301 | South Newport River (Daymark 135), Georgia (sub) | Sub | 31.5750° N | 81.1900° W
8468448 | South Norwalk, Norwalk River, Connecticut | Ref | 41.0967° N | 73.4150° W
8468448 | South Norwalk, Norwalk River, Connecticut (sub) | Sub | 41.0967° N | 73.4150° W
8673171 | South Ossabaw Island, Bear River, Georgia | Ref | 31.7230° N | 81.1417° W
8779749 | South Padre Island, Brazos Santiago Pass, Texas | Ref | 26.0674° N | 97.1548° W
8760551 | South Pass, Louisiana | Ref | 28.9900° N | 89.1400° W
9450341 | South Pass, Sukkwan Strait, Tlevak Strait, Alaska | Sub | 55.1667° N | 132.8700° W
PCT4111_1 | South Passage Point, 3 miles east of, Chatham Strait, Alaska Current | Sub | 57.7667° N | 134.8333° W
8765026 | South Point, Marsh Island, Atchafalaya Bay, Louisiana | Sub | 29.4850° N | 91.7633° W
8570536 | South Point, Sinepuxent Neck, Chincoteague Bay, Maryland | Ref | 38.2150° N | 75.1917° W
8570536 | South Point, Sinepuxent Neck, Chincoteague Bay, Maryland (sub) | Sub | 38.2150° N | 75.1917° W
8722956 | South Port Everglades, ICWW, Florida | Ref | 26.0817° N | 80.1167° W
ACT7751_1 | South River (Depth 13ft), Doboy Sound, Georgia Current | Sub | 31.3667° N | 81.3117° W
ACT7751_2 | South River (Depth 21ft), Doboy Sound, Georgia Current | Sub | 31.3667° N | 81.3117° W
9410135 | South San Diego Bay, California | Ref | 32.6291° N | 117.1080° W
9414391 | South San Francisco, San Francisco Bay, California | Sub | 37.6667° N | 122.3900° W
ACT6586_1 | South Santee River entrance (Depth 5ft), South Carolina Current | Sub | 33.1200° N | 79.2750° W
8447504 | South Yarmouth, Bass River, Nantucket Sound, Massachusetts | Sub | 41.6650° N | 70.1833° W
ACT7626_1 | South of Kilkenny Creek Entrance, Bear River, St. Catherines Sound, Georgia Current | Sub | 31.7583° N | 81.1733° W
8661866 | South of Sam Worth Game Management Area, Great Pee Dee River, South Carolina | Sub | 33.4683° N | 79.1883° W
ACT7181_1 | Southeast Channel entrance, Port Royal Sound, South Carolina Current | Sub | 32.1333° N | 80.5833° W
9414262 | Southeast Farallon Island, California | Sub | 37.7000° N | 123.0000° W
8760416 | Southeast Pass, Mississippi River, Louisiana | Sub | 29.1167° N | 89.0450° W
PCT3701_1 | Southern entrance to Keku Strait, Keku Strait, Alaska Current | Sub | 56.5667° N | 133.7167° W
8512114 | Southold, Shelter Island Sound, New York | Sub | 41.0600° N | 72.4133° W
8659084 | Southport, Cape Fear River, North Carolina | Ref | 33.9150° N | 78.0183° W
8659084 | Southport, Cape Fear River, North Carolina (sub) | Sub | 33.9150° N | 78.0183° W
8467726 | Southport, Southport Harbor, Connecticut | Ref | 41.1333° N | 73.2833° W
8416908 | Southport, Townsend Gut, Maine | Sub | 43.8467° N | 69.6617° W
ACT8416_1 | Southwest Channel (S of Egmont Key) (Depth 15ft), Tampa Bay, Florida Current | Sub | 27.5617° N | 82.7673° W
8722496 | Southwest Fork (spillway), Loxahatchee River, Florida | Sub | 26.9350° N | 80.1433° W
8722494 | Southwest Fork, 0.5 mile above entrance, Loxahatchee River, Florida | Sub | 26.9433° N | 80.1200° W
8413564 | Southwest Harbor, Mount Desert Island, Maine | Sub | 44.2750° N | 68.3133° W
8760959 | Southwest Pass, Mississippi River, Louisiana | Sub | 28.9317° N | 89.4283° W
8765551 | Southwest Pass, Vermilion Bay, Louisiana | Sub | 29.5800° N | 92.0350° W
ACT7301_1 | Spanish Wells, Calibogue Sound (Depth 30ft), Calibogue Sound, South Carolina Current | Sub | 32.1867° N | 80.7850° W
9448009 | Spee-Bi-Dah, Washington | Ref | 48.0883° N | 122.3223° W
ACT5141_1 | Spesutie Island, channel north of (Depth 7ft), Chesapeake Bay, Maryland Current | Sub | 39.4805° N | 76.0817° W
PCT3756_1 | Spike Rock, Wrangell Narrows, Alaska Current | Sub | 56.6010° N | 132.9760° W
8656467 | Spooner Creek, North Carolina | Ref | 34.7250° N | 76.8033° W
8727843 | Spring Warrior Creek, Florida | Ref | 29.9200° N | 83.6717° W
8661070 | Springmaid Pier, South Carolina | Ref | 33.6550° N | 78.9183° W
9457262 | Spruce Island (north side), Alaska | Sub | 57.9383° N | 152.4170° W
8518903 | Spuyten Duyvil Creek Entrance, Hudson River, New York | Ref | 40.8783° N | 73.9250° W
8518903 | Spuyten Duyvil Creek Entrance, Hudson River, New York (sub) | Sub | 40.8783° N | 73.9250° W
8422687 | Squamscott River RR. Bridge, Piscataqua River, New Hampshire | Sub | 43.0533° N | 70.9133° W
8448942 | Squibnocket Point, Martha's Vineyard, Massachusetts | Sub | 41.3117° N | 70.7683° W
8720587 | St. Augustine Beach, Florida | Ref | 29.8567° N | 81.2633° W
8720587 | St. Augustine Beach, Florida (sub) | Sub | 29.8567° N | 81.2633° W
8720576 | St. Augustine, city dock, Florida | Sub | 29.8917° N | 81.3100° W
9462944 | St. Catherine Cove, Unimak Island, Alaska | Sub | 55.0100° N | 163.5070° W
ACT7641_1 | St. Catherines Sound Entrance (Depth 10ft), St. Catherines Sound, Georgia Current | Sub | 31.7150° N | 81.1405° W
8728626 | St. George Island, 12th St. W (bayside), St. George Sound, Florida | Ref | 29.6533° N | 84.8967° W
8728626 | St. George Island, 12th St. W (bayside), St. George Sound, Florida (sub) | Sub | 29.6533° N | 84.8967° W
8728548 | St. George Island, East End, St. George Sound, Florida | Sub | 29.6867° N | 84.7867° W
8728486 | St. George Island, NE end, St. George Sound, Florida | Ref | 29.7667° N | 84.7000° W
8728552 | St. George Island, Rattlesnake Cove, St. George Sound, Florida | Sub | 29.6917° N | 84.7917° W
8728669 | St. George Island, Sikes Cut, St. George Sound, Florida | Ref | 29.6133° N | 84.9583° W
8519112 | St. George, Staten Island, New York | Sub | 40.6433° N | 74.0733° W
8551973 | St. Georges, Chesapeake and Delaware Canal, Delaware | Sub | 39.5550° N | 75.6483° W
8725393 | St. James City, Pine Island, Florida | Sub | 26.4917° N | 82.0817° W
SJR9801_8 | St. Johns River Entrance (between jetties), Florida Current (16d) | Ref | 30.4003° N | 81.3858° W
8728958 | St. Joseph Point, St. Joseph Bay, Florida | Ref | 29.8733° N | 85.3900° W
8722207 | St. Lucie, Indian River, Florida | Sub | 27.4800° N | 80.3333° W
ACT8666_1 | St. Marks River approach, Apalachee Bay, Florida Current | Sub | 30.0467° N | 84.1800° W
8728130 | St. Marks lighthouse, Apalachee Bay, Florida | Ref | 30.0783° N | 84.1783° W
8728142 | St. Marks, St. Marks River, Apalachee Bay, Florida | Sub | 30.1533° N | 84.2033° W
ACT8676_1 | St. Marks, St. Marks River, Apalachee Bay, Florida Current | Sub | 30.1550° N | 84.2017° W
8679997 | St. Marys Entrance, North Jetty, Georgia | Sub | 30.7200° N | 81.4450° W
8679964 | St. Marys, St. Marys River, Georgia | Ref | 30.7200° N | 81.5483° W
8679964 | St. Marys, St. Marys River, Georgia (sub) | Sub | 30.7200° N | 81.5483° W
PCT5871_1 | St. Mathew I., southwest coast, Alaska Current | Sub | 60.3500° N | 172.7167° W
9466203 | St. Matthew Island, Bering Sea, Alaska | Sub | 60.3583° N | 172.7150° W
9468132 | St. Michael, Norton Sound, Alaska | Ref | 63.4750° N | 162.0270° W
9468132 | St. Michael, Norton Sound, Alaska (sub) | Sub | 63.4750° N | 162.0270° W
8572342 | St. Michaels, Miles River, Chesapeake Bay, Maryland | Ref | 38.7867° N | 76.2217° W
8572342 | St. Michaels, Miles River, Chesapeake Bay, Maryland (sub) | Sub | 38.7867° N | 76.2217° W
8572313 | St. Michaels, San Domingo Creek, Chesapeake Bay, Maryland | Sub | 38.7750° N | 76.2333° W
8726520 | St. Petersburg, Tampa Bay, Florida | Ref | 27.7606° N | 82.6269° W
8677344 | St. Simons Lighthouse, St. Simons Island, Georgia | Ref | 31.1317° N | 81.3967° W
8677344 | St. Simons Lighthouse, St. Simons Island, Georgia (sub) | Sub | 31.1317° N | 81.3967° W
TEC3499 | St. Simons Sound Bar, Georgia | Sub | 31.1000° N | 81.3167° W
ACT1636_1 | Stage Harbor, west of Morris Island, Nantucket Sound, Massachusetts Current | Sub | 41.6567° N | 69.9750° W
8469198 | Stamford Harbor, Stamford, Connecticut | Ref | 41.0383° N | 73.5467° W
TWC1131 | Stanwood, Stillaguamish River, Washington | Sub | 48.2167° N | 122.3667° W
ACT6961_1 | State Hwy. 7 bridge, Ashley River, Charleston Harbor, South Carolina Current | Sub | 32.8372° N | 79.9820° W
8720582 | State Road 312, Matanzas River, ICWW, Florida | Ref | 29.8667° N | 81.3067° W
8720692 | State Road A1A Bridge, Florida | Ref | 29.7045° N | 81.2279° W
8537416 | Stathems Neck, Stow Creek, Delaware River, New Jersey | Sub | 39.4067° N | 75.4050° W
8668601 | Station Creek, County Landing, South Carolina | Sub | 32.3250° N | 80.6017° W
8668836 | Station Creek, west end, South Carolina | Sub | 32.2800° N | 80.6383° W
9450578 | Steamboat Bay, Noyes Island, Gulf of Esquibel, Alaska | Sub | 55.5333° N | 133.6370° W
8667075 | Steamboat Landing, Steamboat Creek, North Edisto River, South Carolina | Sub | 32.6033° N | 80.2867° W
9415414 | Steamboat Slough, Snug Harbor Marina, Sacramento River, California | Sub | 38.1833° N | 121.6550° W
8411801 | Steele Harbor Island, Maine | Sub | 44.4933° N | 67.5433° W
8534778 | Steelmanville, Patcong Ck., 2.5 n.mi. above ent, Great Egg Harbor Bay, New Jersey | Sub | 39.3350° N | 74.5967° W
8447281 | Steep Brook, Taunton River, Narragansett Bay, Rhode Island | Sub | 41.7400° N | 71.1317° W
9446714 | Steilacoom, Cormorant Passage, Puget Sound, Washington | Sub | 47.1733° N | 122.6030° W
8727695 | Steinhatchee River ent., Deadman Bay, Florida | Sub | 29.6717° N | 83.3900° W
TWC2319 | Steller Cove, Attu Island, Alaska | Sub | 52.9667° N | 172.9000° E
8535357 | Stites Sound, Townsends Inlet, New Jersey | Sub | 39.1200° N | 74.7550° W
9414883 | Stockton, San Joaquin River, California | Sub | 37.9583° N | 121.2900° W
8535581 | Stone Harbor, Great Channel, Hereford Inlet, New Jersey | Ref | 39.0567° N | 74.7650° W
8411411 | Stone Island, Machias Bay, Maine | Sub | 44.6033° N | 67.3683° W
8414348 | Stonington, Deer Isle, Penobscot Bay, Maine | Sub | 44.1533° N | 68.6617° W
ACT6976_1 | Stono Inlet, Stono River, South Carolina Current | Sub | 32.6267° N | 79.9933° W
8574931 | Stony Creek, Patapsco River, Maryland | Sub | 39.1633° N | 76.5267° W
9454571 | Storey Island (north side), Alaska | Ref | 60.7317° N | 147.4370° W
8533365 | Stouts Creek, Barnegat Bay, New Jersey | Ref | 39.8450° N | 74.1517° W
8533365 | Stouts Creek, Barnegat Bay, New Jersey (sub) | Sub | 39.8450° N | 74.1517° W
8764025 | Stouts Pass At Six Mile Lake, Louisiana | Ref | 29.7433° N | 91.2300° W
8466797 | Stratford, I-95 bridge, Housatonic River, Connecticut | Sub | 41.2033° N | 73.1117° W
8535163 | Strathmere, Strathmere Bay, Corson Inlet, New Jersey | Sub | 39.2000° N | 74.6567° W
9448876 | Strawberry Bay, Cypress Island, Washington | Sub | 48.5650° N | 122.7220° W
8722357 | Stuart, St. Lucie River, Florida | Sub | 27.2000° N | 80.2583° W
8417271 | Sturgeon Island, Merrymeeting Bay, Kennebec River, Maine | Sub | 43.9817° N | 69.8350° W
8638455 | Sturgeon Point, James River, Virginia | Sub | 37.3067° N | 77.0067° W
ACT6356_1 | Sugarloaf Island, 0.2 mile S of (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.7125° N | 76.7138° W
8724326 | Sugarloaf Key, Pirates Cove, Florida | Sub | 24.6533° N | 81.5150° W
8724327 | Sugarloaf Key, east side, Tarpon Creek, Florida | Sub | 24.6283° N | 81.5100° W
8724368 | Sugarloaf Key, north end, Bow Channel, Florida | Sub | 24.6933° N | 81.5550° W
8724347 | Sugarloaf Key, northeast side, Bow Channel, Florida | Sub | 24.6717° N | 81.5333° W
9415498 | Suisun City, Suisun Slough, Suisun Bay, California | Sub | 38.2367° N | 122.0300° W
9415265 | Suisun Slough entrance, Suisun Bay, California | Ref | 38.1283° N | 122.0730° W
9415265 | Suisun Slough entrance, Suisun Bay, California (sub) | Sub | 38.1283° N | 122.0730° W
PCT3256_1 | Sukkwan Narrows, Tlevak Strait, Alaska Current | Sub | 55.1983° N | 132.8240° W
ACT6671_1 | Sullivans I., 0.7 mi. NE of Ft. Sumter, Charleston Harbor, South Carolina Current | Sub | 32.7620° N | 79.8675° W
TEC3047 | Sullivans Island (outer coast), South Carolina | Sub | 32.7667° N | 79.8333° W
9450421 | Sulzer, Hetta Inlet, Alaska | Sub | 55.2850° N | 132.6220° W
8667493 | Summerhouse Point, Bull River, Coosaw River, South Carolina | Sub | 32.5267° N | 80.5733° W
8724267 | Summerland Key, Niles Channel Bridge, Florida | Sub | 24.6600° N | 81.4367° W
8724266 | Summerland Key, Niles Channel South, Florida | Sub | 24.6517° N | 81.4350° W
8724276 | Summerland Key, southwest side, Kemp Channel, Florida | Sub | 24.6500° N | 81.4467° W
8552125 | Summit Bridge, Chesapeake and Delaware Canal, Delaware | Sub | 39.5333° N | 75.7333° W
9465283 | Summit Island, NE side, Togiak Bay, Alaska | Ref | 58.8467° N | 160.2100° W
PCT3716_1 | Summit Island, west of, Keku Strait, Alaska Current | Sub | 56.6765° N | 133.7325° W
PCT3636_1 | Sumner Island, 1.8 miles south of, Sumner Strait, Alaska Current | Sub | 56.3667° N | 133.8167° W
9451163 | Sumner Island, Alaska | Sub | 56.4100° N | 133.7930° W
8672875 | Sunbury, Sunbury Channel, Georgia | Ref | 31.7667° N | 81.2783° W
8672875 | Sunbury, Sunbury Channel, Georgia (sub) | Sub | 31.7667° N | 81.2783° W
8723087 | Sunny Isles, Biscayne Creek, Florida | Sub | 25.9283° N | 80.1300° W
8658654 | Sunny Point Army Base, Wharf no.1, Cape Fear River, North Carolina | Sub | 33.9900° N | 77.9567° W
8635959 | Sunnybank, Little Wicomico River, Chesapeake Bay, Virginia | Sub | 37.8867° N | 76.2667° W
8659899 | Sunset Beach Bridge, North Carolina | Sub | 33.8817° N | 78.5100° W
8659897 | Sunset Beach Pier, North Carolina | Ref | 33.8650° N | 78.5067° W
8659897 | Sunset Beach Pier, North Carolina (sub) | Sub | 33.8650° N | 78.5067° W
9447951 | Sunset Beach, Whidbey Island, Strait of Juan de Fuca, Washington | Sub | 48.2833° N | 122.7280° W
9462711 | Surf Bay, Akutan Bay, Alaska | Ref | 54.1508° N | 165.6150° W
9452672 | Surge Bay, Yakobi Island, outer coast, Alaska | Sub | 58.0183° N | 136.5280° W
ACT7701_1 | Sutherland Bluff, Sapelo River, Sapelo Sound, Georgia Current | Sub | 31.5483° N | 81.3333° W
8720782 | Sutherlands Still, Dunns Creek, Florida | Sub | 29.5717° N | 81.6067° W
9458665 | Sutwik Island, West End, Alaska | Ref | 56.5400° N | 157.3270° W
TEC4299 | Suwannee River entrance, Florida | Sub | 29.2833° N | 83.1500° W
8727577 | Suwannee, Salt Creek, Florida | Sub | 29.3283° N | 83.1517° W
8535805 | Swain Channel, Taylor Sound, Cape May Inlet, New Jersey | Sub | 38.9800° N | 74.8633° W
ACT5046_1 | Swan Point, 1.6 miles northwest of, Chesapeake Bay, Maryland Current | Sub | 39.1625° N | 76.3047° W
ACT5036_1 | Swan Point, 2.7 n.mi. SW of (Depth 14ft), Chesapeake Bay, Maryland Current | Sub | 39.1080° N | 76.3053° W
ACT5036_2 | Swan Point, 2.7 n.mi. SW of (Depth 27ft), Chesapeake Bay, Maryland Current | Sub | 39.1080° N | 76.3053° W
ACT5846_1 | Swan Point, Potomac River, Virginia Current | Sub | 38.2733° N | 76.9450° W
9452368 | Swanson Harbor, Icy Strait, Alaska | Sub | 58.2150° N | 135.1270° W
9461380 | Sweeper Cove, Adak Island, Alaska | Ref | 51.8633° N | 176.6320° W
PCT0116_1 | Sweetwater Channel, southwest of (Depth 14ft), San Diego Bay, California Current | Sub | 32.6450° N | 117.1228° W
8534002 | Sweetwater, Mullica River Marina, Mullica River, New Jersey | Sub | 39.6250° N | 74.6417° W
9448682 | Swinomish Channel entrance, Padilla Bay, Washington | Ref | 48.4583° N | 122.5130° W
9451468 | Symonds Bay, Biorka Island, Sitka Sound, Alaska | Sub | 56.8567° N | 135.5200° W
9451001 | Table Bay, Kuiu Island, Alaska | Sub | 56.1667° N | 134.2450° W
9446486 | Tacoma Narrows Bridge, Puget Sound, Washington | Sub | 47.2717° N | 122.5520° W
9446484 | Tacoma, Commencement Bay, Sitcum Waterway, Puget Sound, Washington | Ref | 47.2667° N | 122.4133° W
9446484 | Tacoma, Commencement Bay, Sitcum Waterway, Puget Sound, Washington (sub) | Sub | 47.2667° N | 122.4133° W
8538886 | Tacony-Palmyra Bridge, New Jersey | Ref | 40.0119° N | 75.0430° W
9436101 | Taft, Siletz Bay, Oregon | Sub | 44.9267° N | 124.0130° W
TWC1487 | Tah Bay, Alaska | Sub | 54.8333° N | 132.3333° W
9446375 | Tahlequah, Neil Pt., Dalco Passage, Vashon I., Puget Sound, Washington | Sub | 47.3333° N | 122.5070° W
9441644 | Taholah, Washington | Ref | 47.3482° N | 124.2848° W
9452434 | Taiyasanka Harbor, Taiya Inlet, Lynn Canal, Alaska | Sub | 59.3017° N | 135.4280° W
9452671 | Takanis Bay, Yakobi Island, outer coast, Alaska | Sub | 57.9283° N | 136.5200° W
9456992 | Takli Island, Shelikof Strait, Alaska | Sub | 58.0633° N | 154.4770° W
9455347 | Takoma Cove, Port Dick, Alaska | Sub | 59.2617° N | 150.9820° W
9452123 | Taku Harbor, Alaska | Sub | 58.0683° N | 134.0120° W
9452124 | Taku Point, Taku Inlet, Alaska | Sub | 58.4000° N | 134.0150° W
8532721 | Tall Pines Camp, Metedeconk River, New Jersey | Sub | 40.0583° N | 74.1167° W
9450273 | Tamgas Harbor, Annette Island, Alaska | Sub | 55.0667° N | 131.5420° W
ACT8411_1 | Tampa Bay Entrance (Egmont Channel), Florida Current (15d) | Ref | 27.6043° N | 82.7603° W
9461138 | Tanaga Bay, Tanaga Island, Alaska | Sub | 51.7183° N | 177.9970° W
1633227 | Tanapag Harbor, Saipan Island, Marianas | Ref | 15.2267° N | 145.7370° E
8633532 | Tangier Island, Chesapeake Bay, Virginia | Ref | 37.8283° N | 75.9933° W
8633532 | Tangier Island, Chesapeake Bay, Virginia (sub) | Sub | 37.8283° N | 75.9933° W
TPT2707 | Taongi Atoll, Marshall Islands | Sub | 14.5667° N | 168.9500° E
8635881 | Tappahannock, Rappahannock River, Virginia | Sub | 37.9300° N | 76.8567° W
9451953 | Target Island, Mitchell Bay, Kootznahoo Inlet, Alaska | Ref | 57.5333° N | 134.4170° W
TWC0933 | Tarlatt Slough, Willapa Bay, Washington | Sub | 46.3700° N | 124.0050° W
ACT1841_1 | Tarpaulin Cove, 1.5 miles east of, Vineyard Sound, Massachusetts Current | Sub | 41.4717° N | 70.7250° W
8725362 | Tarpon Bay, Sanibel Island, Florida | Ref | 26.4433° N | 82.0817° W
8724334 | Tarpon Creek, Upper Sugarloaf Sound, Florida | Sub | 24.6300° N | 81.5167° W
8726905 | Tarpon Springs, Anclote River, Florida | Sub | 28.1600° N | 82.7683° W
9452749 | Tarr Inlet, Glacier Bay, Alaska | Ref | 58.9648° N | 136.8776° W
8518919 | Tarrytown, Hudson River, New York | Sub | 41.0783° N | 73.8700° W
9442971 | Tatoosh Island, Cape Flattery, Strait of Juan de Fuca, Washington | Sub | 48.3917° N | 124.7370° W
TPT2865 | Tau Island, Manua Islands, American Samoa | Sub | 14.2167° S | 169.5333° W
8723748 | Tavernier Creek, Hwy. 1 bridge, Hawk Channel, Florida | Sub | 25.0033° N | 80.5300° W
8723747 | Tavernier Harbor, Hawk Channel, Florida | Sub | 25.0050° N | 80.5167° W
8553069 | Taylors Bridge, Blackbird Creek, Delaware River, Delaware | Sub | 39.4050° N | 75.5983° W
8571752 | Taylors Island, Slaughter Creek, Little Choptank River, Maryland | Sub | 38.4667° N | 76.2950° W
8761993 | Tchefuncta River, Lake Pontchartrain, Louisiana | Sub | 30.3783° N | 90.1600° W
8744663 | Tchoutacabouffa River Entrance, Mississippi | Ref | 30.4417° N | 88.9733° W
ACT6301_1 | Teaches Hole Channel (Depth 10ft), Ocracoke Inlet, Pamlico Sound, North Carolina Current | Sub | 35.0792° N | 76.0047° W
8571269 | Teague Creek, Manokin River, Chesapeake Bay, Maryland | Sub | 38.1083° N | 75.8383° W
TWC1723 | Tebenkof Bay, Kuiu Island, Alaska | Sub | 56.4167° N | 134.1333° W
9449988 | Telegraph Bay, Washington | Ref | 48.4433° N | 122.8050° W
9469239 | Teller, Port Clarence, Alaska | Ref | 65.2667° N | 166.3530° W
9469239 | Teller, Port Clarence, Alaska (sub) | Sub | 65.2667° N | 166.3530° W
9440357 | Temco Kalama Terminal, Columbia River, Washington | Ref | 45.9867° N | 122.8367° W
9452386 | Tenakee Springs, Tenakee Inlet, Alaska | Sub | 57.7800° N | 135.2120° W
8415809 | Tenants Harbor, Maine | Sub | 43.9650° N | 69.2167° W
PCT3491_1 | Tenass Island, 0.3 mile SSW of, El Capitan Passage, Alaska Current | Sub | 55.9867° N | 133.3048° W
TEC3787 | Tequesta, Loxahatchee River, Florida | Sub | 26.9500° N | 80.1017° W
TEC3789 | Tequesta, North Fork entrance, Loxahatchee River, Florida | Sub | 26.9517° N | 80.1017° W
8722486 | Tequesta, North Fork, Loxahatchee River, Florida | Sub | 26.9600° N | 80.1050° W
ACT8031_2 | Terminal Channel (north end) (Depth 17ft), St. Johns River, Florida Current | Sub | 30.3570° N | 81.6180° W
ACT8031_3 | Terminal Channel (north end) (Depth 27ft), St. Johns River, Florida Current | Sub | 30.3570° N | 81.6180° W
ACT8031_1 | Terminal Channel (north end) (Depth 7ft), St. Johns River, Florida Current | Sub | 30.3570° N | 81.6180° W
9415257 | Terminous, South Fork, Mokelumne River, California | Sub | 38.1100° N | 121.4980° W
9457493 | Terror Bay (southwest), Kodiak Island, Alaska | Ref | 57.7440° N | 153.1955° W
8764044 | Tesoro Marine Term., Atchafalaya River, Louisiana | Ref | 29.6675° N | 91.2376° W
8638450 | Tettington, James River, Virginia | Ref | 37.2400° N | 76.9433° W
8761819 | Texaco Dock, Hackberry Bay, Louisiana | Ref | 29.4017° N | 90.0383° W
TEC4513 | Texas City, Turning Basin, Galveston Bay, Texas | Sub | 29.3833° N | 94.8833° W
8763535 | Texas Gas Platform, Caillou Bay, Louisiana | Ref | 29.1748° N | 90.9764° W
8770822 | Texas Point, Sabine Pass, Texas | Ref | 29.6894° N | 93.8419° W
8775296 | Texas State Aquarium, Corpus Christi, Texas | Ref | 27.8149° N | 97.3892° W
8447436 | Texas Tower, Georges Shoal | Sub | 41.6883° N | 67.7600° W
8518750 | The Battery, New York Harbor, New York | Ref | 40.7006° N | 74.0142° W
PCT3826_1 | The Brothers, 2 miles east of, Stephens Passage, Alaska Current | Sub | 57.3000° N | 133.7167° W
9451785 | The Brothers, Stephens Passage, Alaska | Ref | 57.2950° N | 133.7970° W
9451785 | The Brothers, Stephens Passage, Alaska (sub) | Sub | 57.2950° N | 133.7970° W
8665637 | The Cove, Fort Moultrie, South Carolina | Sub | 32.7633° N | 79.8567° W
ACT6721_1 | The Cove, entrance on the Cove Range, Charleston Harbor, South Carolina Current | Sub | 32.7675° N | 79.8720° W
8451301 | The Glen, Sakonnet River, Rhode Island | Sub | 41.5583° N | 71.2367° W
ACT8651_1 | The Narrows (Indian Rocks Beach Bridge), Florida Current | Sub | 27.8767° N | 82.8500° W
PCT3081_1 | The Narrows, Alaska Current | Sub | 56.3678° N | 132.1027° W
PCT3506_1 | The Narrows, west of, Aneskett Point, El Capitan Passage, Alaska Current | Sub | 56.1602° N | 133.3380° W
8761402 | The Rigolets, U.S. Highway 90, Louisiana | Ref | 30.1667° N | 89.7367° W
PCT3261_1 | The Sentinels, 1 mile west of, Tlevak Strait, Alaska Current | Sub | 55.1833° N | 133.0167° W
9451349 | The Summit, Keku Strait, Alaska | Ref | 56.6824° N | 133.7369° W
9451349 | The Summit, Keku Strait, Alaska (sub) | Sub | 56.6824° N | 133.7369° W
ACT6876_1 | The Tee, 0.4 mile southwest of, Cooper River, Charleston Harbor, South Carolina Current | Sub | 33.0633° N | 79.9297° W
ACT6881_1 | The Tee, Cooper River, Charleston Harbor, South Carolina Current | Sub | 33.0658° N | 79.9230° W
9451561 | Thomas Bay, Frederick Sound, Alaska | Sub | 56.9967° N | 132.7850° W
8673812 | Thomas Landing, S. Newport River, Georgia | Sub | 31.6433° N | 81.2567° W
8575737 | Thomas Point Shoal Light, Chesapeake Bay, Maryland | Sub | 38.9000° N | 76.4333° W
ACT4971_1 | Thomas Pt. Shoal Lt., 0.5 n.mi. SE of (Depth 16ft), Chesapeake Bay, Maryland Current | Sub | 38.8910° N | 76.4270° W
ACT4971_2 | Thomas Pt. Shoal Lt., 0.5 n.mi. SE of (Depth 33ft), Chesapeake Bay, Maryland Current | Sub | 38.8910° N | 76.4270° W
ACT4961_1 | Thomas Pt. Shoal Lt., 1.8 mi. SW of, Chesapeake Bay, Maryland Current | Sub | 38.8750° N | 76.4617° W
ACT4966_1 | Thomas Pt. Shoal Lt., 2.0 n.mi. east of (Depth 22ft), Chesapeake Bay, Maryland Current | Sub | 38.8958° N | 76.3868° W
8415709 | Thomaston, St. George River, Maine | Ref | 44.0717° N | 69.1817° W
8415709 | Thomaston, St. George River, Maine (sub) | Sub | 44.0717° N | 69.1817° W
9450970 | Thoms Point, Zimovia Strait, Alaska | Ref | 56.1183° N | 132.0780° W
9450970 | Thoms Point, Zimovia Strait, Alaska (sub) | Sub | 56.1183° N | 132.0780° W
9450938 | Thorne Island, Whale Passage, Alaska | Sub | 56.0583° N | 132.9680° W
8661703 | Thoroughfare Creek entrance, Waccamaw River, South Carolina | Ref | 33.5067° N | 79.1450° W
TWC2047 | Three Saints Bay, Alaska | Sub | 57.1167° N | 153.5167° W
TWC2105 | Three Star Point, Alaska | Sub | 55.9000° N | 159.1667° W
8675843 | Threemile Cut entrance, Darien River, Georgia | Sub | 31.3567° N | 81.3767° W
8511171 | Threemile Harbor entrance, Gardiners Bay, Long Island, New York | Ref | 41.0350° N | 72.1900° W
8511171 | Threemile Harbor entrance, Gardiners Bay, Long Island, New York (sub) | Sub | 41.0350° N | 72.1900° W
9415193 | Threemile Slough entrance, San Joaquin River, California | Ref | 38.0867° N | 121.6850° W
9415193 | Threemile Slough entrance, San Joaquin River, California (sub) | Sub | 38.0867° N | 121.6850° W
9415236 | Threemile Slough, Sacramento River, California | Sub | 38.1067° N | 121.7000° W
8518526 | Throgs Neck, New York | Ref | 40.8050° N | 73.7950° W
ACT7486_1 | Thunderbolt, SE of, Wilmington River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 32.0233° N | 81.0450° W
TEC3407 | Thunderbolt, Wilmington River, Georgia | Sub | 32.0333° N | 81.0500° W
9413643 | Tidal Creek, Elkhorn Slough, Monterey Bay, Port San Luis, California | Ref | 36.8333° N | 121.7450° W
9448918 | Tide Point, Cypress Island, Washington | Sub | 48.5867° N | 122.7480° W
9462782 | Tigalda Bay, Tigalda Island, Alaska | Ref | 54.1200° N | 164.9770° W
8720148 | Tiger Point, Pumpkin Hill Creek, Nassau River, Florida | Sub | 30.5017° N | 81.4950° W
PCT1096_1 | Tillamook Bay entrance, Tillamook Bay, Oregon Current | Sub | 45.5622° N | 123.9383° W
9437331 | Tillamook, Hoquarten Slough, Tillamook Bay, Oregon | Sub | 45.4600° N | 123.8450° W
8762675 | Timbalier Island, Timbalier Bay, Louisiana | Sub | 29.0867° N | 90.5267° W
9469439 | Tin City, Bering Sea, Alaska | Ref | 65.5583° N | 167.9750° W
9469439 | Tin City, Bering Sea, Alaska (sub) | Sub | 65.5583° N | 167.9750° W
8537353 | Tindalls Wharf, Cohansey River, Delaware Bay, New Jersey | Sub | 39.3783° N | 75.2350° W
TPT2625 | Tinian Island, Marianas | Sub | 14.9667° N | 145.6167° E
8542885 | Tinicum National Wildlife Refuge, Darby Creek, Pennsylvania | Sub | 39.8783° N | 75.2767° W
8543024 | Tinicum National Wildlife Refuge, Darby Creek, Pennsylvania (2) | Sub | 39.8867° N | 75.2650° W
8518964 | Tivoli, Hudson River, New York | Sub | 42.0583° N | 73.9167° W
8720596 | Tocoi, Florida | Sub | 29.8583° N | 81.5533° W
8678412 | Todd Creek entrance, Satilla River, Georgia | Sub | 30.9717° N | 81.5200° W
9440910 | Toke Point, Willapa Bay, Washington | Ref | 46.7075° N | 123.9669° W
ACT5076_1 | Tolchester Beach, 0.33 n.mi. west of (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 39.2172° N | 76.2483° W
8573364 | Tolchester Beach, Chesapeake Bay, Maryland | Ref | 39.2133° N | 76.2450° W
8573364 | Tolchester Beach, Chesapeake Bay, Maryland (sub) | Sub | 39.2133° N | 76.2450° W
ACT5061_1 | Tolchester Channel, Buoy '22' (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 39.1912° N | 76.2658° W
ACT5056_1 | Tolchester Channel, SW of Bouy '58B' (Depth 17ft), Chesapeake Bay, Maryland Current | Sub | 39.1825° N | 76.2812° W
ACT5056_2 | Tolchester Channel, SW of Bouy '58B' (Depth 25ft), Chesapeake Bay, Maryland Current | Sub | 39.1825° N | 76.2812° W
ACT5066_1 | Tolchester Channel, south of Buoy '38B' (Depth 15ft), Chesapeake Bay, Maryland Current | Sub | 39.1928° N | 76.2878° W
9435362 | Toledo, Yaquina River, Oregon | Sub | 44.6167° N | 123.9370° W
ACT4976_1 | Tolly Point, 1.6 miles east of, Chesapeake Bay, Maryland Current | Sub | 38.9345° N | 76.4170° W
9415469 | Tomales Bay entrance, California | Sub | 38.2283° N | 122.9770° W
ACT6346_1 | Tombstone Point, 0.1 mile E of (Depth 15ft), Beaufort Inlet, North Carolina Current | Sub | 34.7038° N | 76.6862° W
8723918 | Toms Harbor Channel, Hwy. 1 bridge, Florida | Sub | 24.7767° N | 80.9233° W
8723912 | Toms Harbor Cut, Florida | Sub | 24.7833° N | 80.9067° W
8533051 | Toms River (town), Toms River, Barnegat Bay, New Jersey | Ref | 39.9500° N | 74.1983° W
PCT2656_1 | Tongass Islands, east of, Nakat Bay, Dixon Entrance, Alaska Current | Sub | 54.7823° N | 130.7372° W
9439040 | Tongue Point, Astoria, Columbia River, Oregon | Ref | 46.2073° N | 123.7683° W
PCT1176_1 | Tongue Point, northwest of (Depth 15ft), Oregon Current | Sub | 46.2192° N | 123.7667° W
9457152 | Tonki Bay, Alaska | Sub | 58.3167° N | 152.0670° W
8666433 | Toogoodoo Creek, 2 mi. above entrance, North Edisto River, South Carolina | Sub | 32.6683° N | 80.2933° W
9466298 | Tooksook Bay, Nelson Island, Alaska | Ref | 60.5167° N | 165.1330° W
PCT3346_1 | Toti Island, 1.1 miles west of, Alaska Current | Sub | 55.4167° N | 133.1500° W
8723467 | Totten Key, west side, Biscayne Bay, Florida | Sub | 25.3783° N | 80.2567° W
ACT6706_1 | Town Creek Lower Reach, Charleston Harbor, South Carolina Current | Sub | 32.7925° N | 79.9245° W
ACT6711_1 | Town Creek, 0.2 mile above bridge, Charleston Harbor, South Carolina Current | Sub | 32.8053° N | 79.9317° W
8573903 | Town Point Wharf, Elk River, Maryland | Ref | 39.5033° N | 75.9167° W
8573903 | Town Point Wharf, Elk River, Maryland (sub) | Sub | 39.5033° N | 75.9167° W
8638406 | Town Point, Nansemond River, Virginia | Sub | 36.8833° N | 76.5083° W
8535309 | Townsend Sound, Townsends Inlet, New Jersey | Sub | 39.1467° N | 74.7500° W
9445901 | Tracyton, Dyes Inlet, Puget Sound, Washington | Sub | 47.6100° N | 122.6600° W
8635762 | Travis Point, Coan River, Potomac River, Virginia | Sub | 37.9967° N | 76.4667° W
PCT2706_1 | Tree Point, 1 mile east of, Portland Canal, Alaska Current | Sub | 55.0333° N | 130.1667° W
8539993 | Trenton Marine Terminal, Trenton, New Jersey | Ref | 40.1883° N | 74.7550° W
8539993 | Trenton Marine Terminal, Trenton, New Jersey (sub) | Sub | 40.1883° N | 74.7550° W
9462721 | Trident Bay, Akun Island, Aleutian Islands, Alaska | Ref | 54.1400° N | 165.5270° W
9462721 | Trident Bay, Akun Island, Aleutian Islands, Alaska (sub) | Sub | 54.1400° N | 165.5270° W
8721604 | Trident Pier, Port Canaveral, Florida | Ref | 28.4158° N | 80.5931° W
9419059 | Trinidad Harbor, California | Sub | 41.0567° N | 124.1470° W
8656583 | Triple S Marina, Bogue Sd., North Carolina | Sub | 34.6950° N | 76.7117° W
8656590 | Triple S Pier, Atlantic Beach, North Carolina | Ref | 34.6933° N | 76.7117° W
8656590 | Triple S Pier, Atlantic Beach, North Carolina (sub) | Sub | 34.6933° N | 76.7117° W
9445326 | Triton Head, Washington | Sub | 47.6033° N | 122.9820° W
9450463 | Trocadero Bay, Alaska | Ref | 55.3517° N | 132.9381° W
8725439 | Tropical Homesites Landing, Pine Island, Florida | Sub | 26.5483° N | 82.0800° W
TEC1603 | Troy, Hudson River, New York | Sub | 42.7167° N | 73.7000° W
9442705 | Tskawahyah Island, Cape Alava, Washington | Ref | 48.1711° N | 124.7369° W
8534883 | Tuckahoe, Tuckahoe River, Great Egg Harbor Bay, New Jersey | Ref | 39.2950° N | 74.7483° W
8534883 | Tuckahoe, Tuckahoe River, Great Egg Harbor Bay, New Jersey (sub) | Sub | 39.2950° N | 74.7483° W
ACT1601_1 | Tuckernuck Island, 4.2 miles SSW of, Massachusetts Current | Sub | 41.2262° N | 70.2817° W
ACT1676_1 | Tuckernuck Shoal, off east end, Nantucket Sound, Massachusetts Current | Sub | 41.4050° N | 70.1733° W
8727277 | Tuckers Island, Homosassa River, Florida | Ref | 28.7717° N | 82.6950° W
8727277 | Tuckers Island, Homosassa River, Florida (sub) | Sub | 28.7717° N | 82.6950° W
8534139 | Tuckerton Creek entrance, Little Egg Harbor, New Jersey | Sub | 39.5767° N | 74.3317° W
8534080 | Tuckerton, Tuckerton Creek, Little Egg Harbor, New Jersey | Sub | 39.6017° N | 74.3417° W
8637663 | Tue Marshes Light, York River, Virginia | Sub | 37.2350° N | 76.3850° W
9447773 | Tulalip, Tulalip Bay, Washington | Ref | 48.0650° N | 122.2880° W
9448043 | Tulare Beach, Port Susan, Washington | Ref | 48.1068° N | 122.3473° W
8667076 | Tulifiny River, I-95 bridge, Broad River, South Carolina | Sub | 32.6017° N | 80.9033° W
8745375 | Turkey Creek, Bernard Bayou, Mississippi | Sub | 30.4267° N | 89.0533° W
8518962 | Turkey Point Hudson River NERRS, Hudson River, New York | Ref | 42.0139° N | 73.9392° W
ACT5136_1 | Turkey Point, 1.2 n.mi. SW of (Depth 9ft), Chesapeake Bay, Maryland Current | Sub | 39.4433° N | 76.0338° W
8728360 | Turkey Point, Apalachee Bay, St. James Island, Florida | Ref | 29.9150° N | 84.5117° W
8728360 | Turkey Point, Apalachee Bay, St. James Island, Florida (sub) | Sub | 29.9150° N | 84.5117° W
8723423 | Turkey Point, Biscayne Bay, Florida | Ref | 25.4367° N | 80.3300° W
9451434 | Turn Point, Alaska | Ref | 56.8000° N | 132.9800° W
9451434 | Turn Point, Alaska (sub) | Sub | 56.8000° N | 132.9800° W
PCT4106_1 | Turn Point, Kootznahoo Inlet, Chatham Strait, Alaska Current | Sub | 57.5000° N | 134.5833° W
PCT3796_1 | Turn Point, Wrangell Narrows, Alaska Current | Sub | 56.8078° N | 132.9835° W
8669575 | Turnbridge Landing, Salt Water Creek, South Carolina | Sub | 32.1283° N | 81.0117° W
9448657 | Turner Bay, Similk Bay, Washington | Ref | 48.4450° N | 122.5550° W
ACT6351_2 | Turning Basin (Depth 15ft), Beaufort Inlet, North Carolina Current | Sub | 34.7130° N | 76.6942° W
ACT6351_1 | Turning Basin (Depth 6ft), Beaufort Inlet, North Carolina Current | Sub | 34.7130° N | 76.6942° W
8725649 | Turtle Bay, Charlotte Harbor, Florida | Ref | 26.7967° N | 82.1833° W
8721223 | Turtle Mound, Florida | Ref | 28.9267° N | 80.8250° W
ACT7836_1 | Turtle River, off Allied Chemical Corp, St. Simons Sound, Georgia Current | Sub | 31.1767° N | 81.5250° W
ACT7841_1 | Turtle River, off Andrews Island (Depth 20ft), St. Simons Sound, Georgia Current | Sub | 31.1433° N | 81.5267° W
9455506 | Tutka Bay,Kachemak Bay, Cook Inlet, Alaska | Sub | 59.4317° N | 151.3570° W
9456204 | Tuxedni Channel, Cook Inlet, Alaska | Sub | 60.1533° N | 152.6350° W
PCT3456_1 | Tuxekan Passage, 0.2 mile S of Tuxekan, Alaska Current | Sub | 55.8827° N | 133.2423° W
9450817 | Tuxekan, 0.5 mile south of, Davidson Inlet, Alaska | Sub | 55.8833° N | 133.2430° W
8727348 | Twin Rivers Marina, Crystal River, Florida | Ref | 28.9050° N | 82.6383° W
8727348 | Twin Rivers Marina, Crystal River, Florida (sub) | Sub | 28.9050° N | 82.6383° W
9443644 | Twin Rivers, Strait of Juan de Fuca, Washington | Sub | 48.1750° N | 123.9500° W
9455217 | Two Arm Bay, Harris Bay, Alaska | Sub | 59.6617° N | 150.1080° W
TEC3399 | Tybee Creek entrance, Georgia | Sub | 31.9833° N | 80.8500° W
8670892 | Tybee Light, Savannah River, Georgia | Sub | 32.0283° N | 80.8550° W
8463348 | Tylerville, Connecticut River, Connecticut | Sub | 41.4517° N | 72.4650° W
9453431 | Tyndall Glacier, Icy Bay, Alaska | Sub | 60.0783° N | 141.2750° W
8666659 | U.S. 17 Bridge, Combahee River, South Carolina | Sub | 32.6517° N | 80.6833° W
8662799 | U.S. Highway 17 bridge, South Santee River, South Carolina | Sub | 33.1850° N | 79.4067° W
8772447 | USCG Freeport, Texas | Ref | 28.9433° N | 95.3025° W
8519050 | USCG Station, The Narrows, New York | Ref | 40.6120° N | 74.0599° W
9462637 | Udagak Strait, Unalaska Island, Alaska | Sub | 53.7367° N | 166.2950° W
9457351 | Ugak Bay (Saltery Cove), Alaska | Sub | 57.4817° N | 152.7180° W
TWC2071 | Uganik Passage, Uganik Bay, Alaska | Sub | 57.8000° N | 153.3000° W
TPT2695 | Ujae Atoll, Marshall Islands | Sub | 9.0333° N | 165.6000° E
9459696 | Ukolnoi Island, Alaska | Sub | 55.2583° N | 161.5370° W
8770625 | Umbrella Point, Trinity Bay, Texas | Ref | 29.6800° N | 94.8683° W
PCT1066_1 | Umpqua River entrance, Oregon Current | Sub | 43.6783° N | 124.1933° W
9468333 | Unalakleet, Alaska | Ref | 63.8750° N | 160.7880° W
9462620 | Unalaska, Dutch Harbor, Alaska | Ref | 53.8792° N | 166.5403° W
9461341 | Unalga Bight, Adak Island, Alaska | Sub | 51.7800° N | 176.8070° W
9458762 | Unavikshak Island, Alaska | Sub | 56.4917° N | 157.7400° W
8447941 | Uncatena Island (south side), Woods Hole, Massachusetts | Sub | 41.5200° N | 70.7083° W
PCT5411_1 | Unga Strait (1.4 miles N of Unga Spit), Shumagin Islands, Alaska Current | Sub | 55.4333° N | 160.7333° W
9445478 | Union, Hood Canal, Washington | Ref | 47.3583° N | 123.0980° W
8761385 | University of New Orleans vicinity, Chef Menteur Pass, Louisiana | Ref | 30.0688° N | 89.8021° W
8729738 | Upper Blackwater River, Florida | Ref | 30.6583° N | 86.9883° W
9452005 | Upper Endicott Arm, North Shore, Stephens Passage, Alaska | Sub | 57.5217° N | 133.0550° W
9414549 | Upper Guadalupe Slough, San Francisco Bay, California | Sub | 37.4350° N | 122.0070° W
8723814 | Upper Matecumbe Key, Hawk Channel, Florida | Sub | 24.9150° N | 80.6317° W
8723828 | Upper Matecumbe Key, west end, Hawk Channel, Florida | Sub | 24.8967° N | 80.6583° W
9455204 | Upper Northwestern Fiord, Harris Bay, Alaska | Ref | 59.7900° N | 150.0320° W
9455204 | Upper Northwestern Fiord, Harris Bay, Alaska (sub) | Sub | 59.7900° N | 150.0320° W
9415584 | Upper drawbridge, Petaluma River, San Pablo Bay, California | Ref | 38.2283° N | 122.6130° W
9415584 | Upper drawbridge, Petaluma River, San Pablo Bay, California (sub) | Sub | 38.2283° N | 122.6130° W
9449911 | Upright Head, Lopez Island, Washington | Ref | 48.5717° N | 122.8850° W
8631287 | Upshur Neck, south end, Virginia | Sub | 37.4667° N | 75.8000° W
8636522 | Urbanna, Rappahannock River, Virginia | Sub | 37.6500° N | 76.5750° W
9455478 | Ushagat Island, Barren Islands, Cook Inlet, Alaska | Sub | 58.9467° N | 152.2680° W
9462582 | Usof Bay, Unalaska Island, Alaska | Sub | 53.5150° N | 166.7900° W
9457728 | Uyak, Uyak Bay, Alaska | Ref | 57.6350° N | 154.0070° W
9457376 | Uzkosti Point, Kupreanof Strait, Alaska | Ref | 57.9283° N | 152.8120° W
8723970 | Vaca Key, Florida Bay, Florida | Ref | 24.7110° N | 81.1065° W
8723950 | Vaca Key-Fat Deer Key bridge, Florida | Sub | 24.7300° N | 81.0300° W
8417911 | Vaill Island, Casco Bay, Maine | Sub | 43.6767° N | 70.1550° W
9454240 | Valdez, Prince William Sound, Alaska | Ref | 61.1250° N | 146.3620° W
9415165 | Vallejo, Mare Island Strait, California | Sub | 38.1117° N | 122.2730° W
9450511 | Vallenar Point, Alaska | Sub | 55.4267° N | 131.8470° W
8729501 | Valparaiso, Florida | Ref | 30.5033° N | 86.4933° W
9440083 | Vancouver, Columbia River, Washington | Ref | 45.6317° N | 122.6970° W
9446366 | Vaughn, Case Inlet, Puget Sound, Washington | Sub | 47.3417° N | 122.7750° W
8720059 | Vaughns Landing, Florida | Ref | 30.6300° N | 81.5767° W
8725889 | Venice Inlet (inside), Florida | Sub | 27.1117° N | 82.4633° W
ACT8351_1 | Venice Inlet, Florida Current | Sub | 27.1133° N | 82.4667° W
8725858 | Venice Municipal Airport, Florida | Ref | 27.0717° N | 82.4533° W
8760849 | Venice, Grand Pass, Louisiana | Ref | 29.2733° N | 89.3517° W
8534770 | Ventnor City, ocean pier, New Jersey | Ref | 39.3350° N | 74.4767° W
8534770 | Ventnor City, ocean pier, New Jersey (sub) | Sub | 39.3350° N | 74.4767° W
9411189 | Ventura, California | Sub | 34.2667° N | 119.2830° W
ACT7591_1 | Vernon R., 1.2 miles S of Possum Point, Ossabaw Sound, Georgia Current | Sub | 31.8983° N | 81.0983° W
8671642 | Vernon View, Burnside River, Georgia | Sub | 31.9267° N | 81.0983° W
8722105 | Vero Beach (ocean), Florida | Sub | 27.6700° N | 80.3600° W
8722125 | Vero Beach, Indian River, Florida | Ref | 27.6317° N | 80.3717° W
8722125 | Vero Beach, Indian River, Florida (sub) | Sub | 27.6317° N | 80.3717° W
PCT3771_1 | Vexation Point, Woody Island, Wrangell Narrows, Alaska Current | Sub | 56.6578° N | 132.9270° W
TWC2073 | Viekoda Bay, Alaska | Sub | 57.9000° N | 153.1667° W
8571773 | Vienna, Nanticoke River, Maryland | Ref | 38.4833° N | 75.8183° W
8571773 | Vienna, Nanticoke River, Maryland (sub) | Sub | 38.4833° N | 75.8183° W
ACT8926_1 | Vieques Passage, Puerto Rico Current | Ref | 18.1883° N | 65.6183° W
ACT8931_1 | Vieques Sound, Puerto Rico Current | Sub | 18.2645° N | 65.5700° W
9450283 | View Cove, Tlevak Strait, Alaska | Sub | 55.0833° N | 133.0170° W
8720554 | Vilano Beach ICWW, Tolomato River, Florida | Ref | 29.9167° N | 81.3000° W
8720554 | Vilano Beach ICWW, Tolomato River, Florida (sub) | Sub | 29.9167° N | 81.3000° W
9464212 | Village Cove, St. Paul Island, Bering Sea, Alaska | Ref | 57.1253° N | 170.2852° W
9464212 | Village Cove, St. Paul Island, Bering Sea, Alaska (sub) | Sub | 57.1253° N | 170.2852° W
8668077 | Village Creek Cemetery, Morgan River, South Carolina | Sub | 32.4167° N | 80.5200° W
8667927 | Village Creek Entrance, Morgan River, South Carolina | Sub | 32.4450° N | 80.5033° W
TWC2067 | Village Islands, Uganik Bay, Alaska | Sub | 57.7833° N | 153.5500° W
PCT3111_1 | Village Islands, Zimovia Strait, Alaska Current | Sub | 56.2167° N | 132.3167° W
9449161 | Village Point, Lummi Island, Washington | Ref | 48.7167° N | 122.7080° W
9451037 | Village Rock, Zimovia Strait, Alaska | Ref | 56.2200° N | 132.2970° W
9451037 | Village Rock, Zimovia Strait, Alaska (sub) | Sub | 56.2200° N | 132.2970° W
8414776 | Vinalhaven, Vinalhaven Island, Penobscot Bay, Maine | Sub | 44.0433° N | 68.8400° W
8448157 | Vineyard Haven Harbor, Vineyard Haven, Massachusetts | Ref | 41.4583° N | 70.6000° W
8639168 | Virginia Beach, Virginia | Sub | 36.8433° N | 75.9717° W
8723214 | Virginia Key, Bear Cut, Biscayne Bay, Florida | Ref | 25.7314° N | 80.1618° W
8723214 | Virginia Key, Bear Cut, Biscayne Bay, Florida (sub) | Sub | 25.7314° N | 80.1618° W
8638888 | Virginia pilot's dock, Lynnhaven Inlet, Chesapeake Bay, Virginia | Sub | 36.9067° N | 76.0900° W
PCT3046_1 | Vixen Point, 3 miles west of, Ernest Sound, Alaska Current | Sub | 55.8500° N | 132.1833° W
8531592 | Waackaack Creek, New Jersey | Sub | 40.4483° N | 74.1433° W
8722059 | Wabasso, Indian River, Florida | Sub | 27.7550° N | 80.4250° W
8662931 | Waccamaw River entrance, Winyah Bay, South Carolina | Ref | 33.3667° N | 79.2550° W
8631044 | Wachapreague, Wachapreague Channel, Virginia | Ref | 37.6078° N | 75.6858° W
8631044 | Wachapreague, Wachapreague Channel, Virginia (sub) | Sub | 37.6078° N | 75.6858° W
8661493 | Wachesaw Landing, Waccamaw River, South Carolina | Sub | 33.5600° N | 79.0850° W
9452632 | Wachusett Inlet, Glacier Bay, Alaska | Sub | 58.9467° N | 136.3330° W
8534043 | Wading River (town), Wading River, Mullica River, New Jersey | Sub | 39.6183° N | 74.4967° W
ACT7031_1 | Wadmalaw Island, Wadmalaw River entrance (Depth 12ft), South Carolina Current | Sub | 32.6650° N | 80.2350° W
1612482 | Waianae, Oahu Island, Hawaii | Sub | 21.4450° N | 158.1920° W
TPT2777 | Waikane, Kaneohe Bay, Oahu Island, Hawaii | Sub | 21.5000° N | 157.8500° W
1612376 | Waimanalo, Oahu Island, Hawaii | Sub | 21.3350° N | 157.6930° W
1611401 | Waimea Bay, Kauai Island, Hawaii | Sub | 21.9567° N | 159.6730° W
1890000 | Wake Island, Pacific Ocean | Ref | 19.2907° N | 166.6176° E
8636499 | Wakema (Fraziers Ferry), Mattaponi River, Virginia | Sub | 37.6500° N | 76.9000° W
8673437 | Walburg Creek entrance, Georgia | Sub | 31.6900° N | 81.1550° W
8416224 | Waldoboro, Medomak River, Maine | Sub | 44.0933° N | 69.3767° W
9434939 | Waldport, Alsea Bay, Oregon | Ref | 44.4344° N | 124.0581° W
9449746 | Waldron Island, Haro Strait, Washington | Ref | 48.6868° N | 123.0376° W
PCT2691_1 | Wales Point, 2 miles south from, Portland Canal, Alaska Current | Sub | 54.6667° N | 130.4833° W
PCT1251_1 | Walker Island, south of (Depth 12ft), Washington Current | Sub | 46.1412° N | 123.0458° W
9446489 | Walkers Landing, Pickering Passage, Puget Sound, Washington | Sub | 47.2817° N | 122.9230° W
8517732 | Wallabout Bay, Brooklyn Navy Yard, East River, New York | Sub | 40.7067° N | 73.9750° W
ACT6311_1 | Wallace Channel (Depth 9ft), Ocracoke Inlet, Pamlico Sound, North Carolina Current | Sub | 35.0797° N | 76.0520° W
8630440 | Wallops Island, Virginia | Sub | 37.8417° N | 75.4783° W
ACT7336_1 | Walls Cut, Turtle Island (Depth 6ft), South Carolina Current | Sub | 32.0817° N | 80.9167° W
8416731 | Walpole, Damariscotta River, Maine | Ref | 43.9333° N | 69.5800° W
PCT5841_1 | Walrus Island, 0.5 mile west of, Pribilof Islands, Alaska Current | Sub | 57.1833° N | 169.9500° W
8724448 | Waltz Key, Waltz Key Basin, Florida | Sub | 24.6467° N | 81.6533° W
8542425 | Wanamaker Bridge, Darby Creek, Pennsylvania | Sub | 39.8767° N | 75.3050° W
ACT6906_1 | Wando River Upper Reach, Turning Basin, Wando River, South Carolina Current | Sub | 32.8333° N | 79.8967° W
8665613 | Wappoo Creek, highway bridge, Ashley River, South Carolina | Sub | 32.7667° N | 79.9733° W
ACT6941_1 | Wappoo Creek, off of, Ashley River, Charleston Harbor, South Carolina Current | Sub | 32.7730° N | 79.9500° W
ACT1811_1 | Waquoit Bay entrance, Nantucket Sound, Massachusetts Current | Sub | 41.5483° N | 70.5300° W
9450492 | Ward Cove, Revillagigedo Channel, Alaska | Sub | 55.3983° N | 131.7270° W
8662071 | Ward's Dock, Pawleys Inlet, South Carolina | Ref | 33.4117° N | 79.1350° W
9415105 | Wards Island, Little Connection Slough, San Joaquin River, California | Ref | 38.0500° N | 121.4969° W
9415105 | Wards Island, Little Connection Slough, San Joaquin River, California (sub) | Sub | 38.0500° N | 121.4969° W
PCT5831_1 | Warehouse Bluff, southwest of, Kuskokwim Bay, Alaska Current | Sub | 59.7833° N | 162.2333° W
8635985 | Wares Wharf, Rappahannock River, Virginia | Ref | 37.8733° N | 76.7833° W
8635985 | Wares Wharf, Rappahannock River, Virginia (sub) | Sub | 37.8733° N | 76.7833° W
8533541 | Waretown, Barnegat Bay, New Jersey | Sub | 39.7917° N | 74.1817° W
ACT2196_1 | Warren, Warren River, Narragansett Bay, Rhode Island Current | Sub | 41.7283° N | 71.2883° W
TWC0883 | Warrenton, Skipanon River, Oregon | Sub | 46.1667° N | 123.9167° W
8729868 | Warrington, 2 miles south of, Pensacola Bay, Florida | Sub | 30.3450° N | 87.2733° W
8593005 | Washington Naval Yard, Anacostia River, DC | Sub | 38.8717° N | 76.9950° W
8594900 | Washington, Potomac River, DC | Ref | 38.8733° N | 77.0217° W
9440047 | Washougal, Columbia River, Washington | Ref | 45.5783° N | 122.3820° W
8448683 | Wasque Point, Chappaquiddick Island, Martha's Vineyard, Massachusetts | Sub | 41.3633° N | 70.4500° W
ACT7441_1 | Wassaw Island, N of E end, Wassaw Sound (Depth 10ft), Savannah River, Georgia Current | Sub | 31.9150° N | 80.9383° W
ACT7571_1 | Wassaw Island, SSW of (Depth 10ft), Ossabaw Sound, Georgia Current | Sub | 31.8567° N | 81.0083° W
ACT7571_2 | Wassaw Island, SSW of (Depth 20ft), Ossabaw Sound, Georgia Current | Sub | 31.8567° N | 81.0083° W
8458694 | Watch Hill Point, Rhode Island | Sub | 41.3050° N | 71.8600° W
9751583 | Water Bay, St. Thomas, Virgin Islands | Ref | 18.3489° N | 64.8642° W
8724189 | Water Key, west end, Big Spanish Channel, Florida | Sub | 24.7400° N | 81.3417° W
8724273 | Water Keys, south end, Harbor Channel, Florida | Sub | 24.7467° N | 81.4500° W
8720211 | Water Treatment Dock, Mayport Naval Station, St Johns River, Florida | Ref | 30.4000° N | 81.4133° W
8720211 | Water Treatment Dock, Mayport Naval Station, St Johns River, Florida (sub) | Sub | 30.4000° N | 81.4133° W
PCT3311_1 | Waterfall Cannery, Ulloa Channel, Alaska Current | Sub | 55.3000° N | 133.2500° W
8454341 | Watson Pier, Boston Neck, Narragansett Bay, Rhode Island | Sub | 41.4600° N | 71.4283° W
8633451 | Watts Island, Chesapeake Bay, Virginia | Sub | 37.7983° N | 75.8967° W
9446291 | Wauna, Carr Inlet, Puget Sound, Washington | Ref | 47.3783° N | 122.6340° W
9439099 | Wauna, Columbia River, Oregon | Ref | 46.1617° N | 123.4089° W
8747766 | Waveland, Mississipi Sound, Mississippi | Ref | 30.2817° N | 89.3667° W
8747766 | Waveland, Mississipi Sound, Mississippi (sub) | Sub | 30.2817° N | 89.3667° W
PCT3221_1 | Webster Point, 1 mile west of, Cordova Bay, Alaska Current | Sub | 54.9667° N | 132.6333° W
TWC0817 | Wedderburn, Rogue River, Oregon | Sub | 42.4333° N | 124.4167° W
8723518 | Wednesday Point, Key Largo, Card Sound, Florida | Sub | 25.3100° N | 80.2983° W
8530645 | Weehawken, Union City, Hudson River, New Jersey | Sub | 40.7650° N | 74.0183° W
8458022 | Weekapaug Point, Block Island Sound, Rhode Island | Ref | 41.3283° N | 71.7617° W
8458022 | Weekapaug Point, Block Island Sound, Rhode Island (sub) | Sub | 41.3283° N | 71.7617° W
8765148 | Weeks Bay, Louisiana | Ref | 29.8372° N | 91.8375° W
8732828 | Weeks Bay, Vermilion Bay, Louisiana | Ref | 30.4169° N | 87.8254° W
8536935 | Weir Creek bridge, Dividing Creek, Delaware Bay, New Jersey | Sub | 39.2500° N | 75.1283° W
9435308 | Weiser Point, Yaquina River, Oregon | Ref | 44.5933° N | 124.0080° W
8720832 | Welaka, St. Johns River, Florida | Ref | 29.4767° N | 81.6750° W
8720832 | Welaka, St. Johns River, Florida (sub) | Sub | 29.4767° N | 81.6750° W
8446613 | Wellfleet, Cape Cod Bay, Massachusetts | Sub | 41.9300° N | 70.0417° W
8419317 | Wells, Webhannet River, Maine | Ref | 43.3200° N | 70.5633° W
8419317 | Wells, Webhannet River, Maine (sub) | Sub | 43.3200° N | 70.5633° W
ACT3501_1 | West 207th Street Bridge, Harlem River, New York Current | Sub | 40.8633° N | 73.9150° W
8724129 | West Bahia Honda Key, Florida | Sub | 24.7800° N | 81.2717° W
8729197 | West Bay Creek, West Bay, St. Andrew Bay, Florida | Sub | 30.2933° N | 85.8583° W
PCT4171_1 | West Channel (narrows), Krestof Sound, Alaska Current | Sub | 57.1500° N | 135.5833° W
ACT1826_1 | West Chop, 0.2 mile west of, Vineyard Sound, Massachusetts Current | Sub | 41.4833° N | 70.6100° W
ACT1801_1 | West Chop, 0.8 mile north of, Nantucket Sound, Massachusetts Current | Sub | 41.4933° N | 70.5950° W
8536764 | West Creek, 0.7 n.mi. above entrance, Delaware Bay, New Jersey | Sub | 39.1883° N | 74.9150° W
8536851 | West Creek, Route 47 bridge, Delaware Bay, New Jersey | Sub | 39.2167° N | 74.9250° W
8533987 | West Creek, Westecunk Creek, Little Egg Harbor, New Jersey | Sub | 39.6317° N | 74.2967° W
PCT2636_1 | West Devil Rock, 2 miles north of, Dixon Entrance, Alaska Current | Sub | 54.7000° N | 131.6000° W
8514961 | West Fire Island, Great South Bay, New York | Sub | 40.6567° N | 73.2050° W
8738043 | West Fowl River Bridge, Alabama | Ref | 30.3766° N | 88.1586° W
8453742 | West Jamestown, Dutch Island Harbor, Conanicut Island, Rhode Island | Ref | 41.4967° N | 71.3867° W
8453742 | West Jamestown, Dutch Island Harbor, Conanicut Island, Rhode Island (sub) | Sub | 41.4967° N | 71.3867° W
PCT3936_1 | West Juneau, NE of (Depth 25ft), Gastineau Channel, Stephens Passage, Alaska Current | Sub | 58.2963° N | 134.4245° W
ACT6966_1 | West Marsh Island, 0.1 mile east of, Ashley River, South Carolina Current | Sub | 32.8283° N | 80.0083° W
8460751 | West Mystic, Mystic River, Long Island Sound, Connecticut | Ref | 41.3433° N | 71.9750° W
8722654 | West Palm Beach Canal, Lake Worth, Florida | Sub | 26.6450° N | 80.0450° W
8728766 | West Pass, Apalachicola Bay, Florida | Sub | 29.6333° N | 85.0967° W
9414507 | West Point Slough, San Francisco Bay, California | Sub | 37.5050° N | 122.1920° W
8636769 | West Point, York River, Virginia | Sub | 37.5350° N | 76.7933° W
9457535 | West Raspberry Island, Alaska | Ref | 58.1072° N | 153.3401° W
8535726 | West Wildwood, Grassy Sound, Hereford Inlet, New Jersey | Sub | 39.0050° N | 74.8267° W
8463409 | Westbrook, Duck Island Roads, Connecticut | Sub | 41.2733° N | 72.4750° W
8534044 | Westecunk Creek entrance, Little Egg Harbor, New Jersey | Sub | 39.6133° N | 74.2633° W
8455189 | Westerly, Pawcatuck River, Rhode Island | Ref | 41.3817° N | 71.8317° W
8455189 | Westerly, Pawcatuck River, Rhode Island (sub) | Sub | 41.3817° N | 71.8317° W
8638339 | Western Branch, Elizabeth River, Virginia | Ref | 36.8232° N | 76.3991° W
8447975 | Westport Harbor, Westport River, Massachusetts | Sub | 41.5083° N | 71.0933° W
9417624 | Westport, California | Sub | 39.6333° N | 123.7830° W
9441102 | Westport, Point Chehalis, Grays Harbor, Washington | Ref | 46.9043° N | 124.1051° W
9441102 | Westport, Point Chehalis, Grays Harbor, Washington (sub) | Sub | 46.9043° N | 124.1051° W
PCT1316_1 | Westport, channel 0.4 mile NE of, Grays Harbor, Washington Current | Sub | 46.9142° N | 124.1083° W
8538601 | Westville, Rt. 47 bridge, Big Timber Creek, New Jersey | Sub | 39.8733° N | 75.1233° W
8728973 | Wetappo Creek, East Bay, St. Andrew Bay, Florida | Sub | 30.0383° N | 85.3933° W
8661913 | Weymouth Plantation, Great Pee Dee River, South Carolina | Sub | 33.4550° N | 79.2050° W
ACT7166_1 | Whale Branch River (Depth 10ft), South Carolina Current | Sub | 32.5267° N | 80.6917° W
8667491 | Whale Branch entrance, Coosaw River, South Carolina | Sub | 32.5250° N | 80.6750° W
8723797 | Whale Harbor Channel, Hwy. 1 bridge, Windley Key, Florida | Sub | 24.9383° N | 80.6100° W
8723795 | Whale Harbor, Windley Key, Hawk Channel, Florida | Sub | 24.9400° N | 80.6083° W
PCT2891_1 | Wharburton Island, Nichols Passage, Alaska Current | Sub | 55.1335° N | 131.6287° W
8658579 | Wharf 3, MOTSU, Cape Fear River, North Carolina | Ref | 34.0233° N | 77.9467° W
8664621 | Wharf Creek entrance, Bulls Bay, South Carolina | Sub | 32.9133° N | 79.6167° W
8722957 | Whiskey Creek, north end, Florida | Sub | 26.0800° N | 80.1117° W
8722971 | Whiskey Creek, south entrance, ICWW, Florida | Sub | 26.0550° N | 80.1133° W
8728694 | White Beach, East Bay, Florida | Ref | 29.7850° N | 84.8983° W
8728853 | White City, ICWW, Florida | Ref | 29.8807° N | 85.2214° W
8775188 | White Point Bay, Texas | Ref | 27.8583° N | 97.4750° W
PCT2716_1 | White Point, Portland Canal, Alaska Current | Sub | 55.5667° N | 130.1167° W
ACT7046_1 | White Point, south of, Dawho River (Depth 12ft), South Carolina Current | Sub | 32.6250° N | 80.2817° W
8571485 | Whitehaven, Wicomico River, Maryland | Sub | 38.2683° N | 75.7883° W
9451741 | Whitestone Narrows, Neva Strait, Alaska | Ref | 57.2500° N | 135.5670° W
8517125 | Whitestone, East River, New York | Sub | 40.7983° N | 73.8133° W
TWC1731 | Whitewater Bay, Admiralty Island, Alaska | Sub | 57.2333° N | 134.6000° W
TEC4169 | Whitewater Bay, Florida | Sub | 25.3167° N | 81.0333° W
9445246 | Whitney Point, Dabob Bay, Washington | Sub | 47.7617° N | 122.8500° W
9454949 | Whittier, Prince William Sound, Alaska | Ref | 60.7783° N | 148.6650° W
9454949 | Whittier, Prince William Sound, Alaska (sub) | Sub | 60.7783° N | 148.6650° W
ACT7051_1 | Whooping Island, Dawho River (Depth 12ft), South Carolina Current | Sub | 32.6367° N | 80.3400° W
8454538 | Wickford, Narragansett Bay, Rhode Island | Ref | 41.5717° N | 71.4450° W
8454538 | Wickford, Narragansett Bay, Rhode Island (sub) | Sub | 41.5717° N | 71.4450° W
8725235 | Wiggins Pass, Cocohatchee River, Florida | Sub | 26.2900° N | 81.8183° W
8667074 | Wiggins, Chehaw River, Combahee River, South Carolina | Sub | 32.6017° N | 80.5417° W
8535838 | Wildwood Crest, Sunset Lake, Cape May Inlet, New Jersey | Sub | 38.9783° N | 74.8367° W
8535835 | Wildwood Crest, ocean pier, New Jersey | Ref | 38.9750° N | 74.8233° W
8638464 | Willcox Wharf, Charles City, James River, Virginia | Ref | 37.3150° N | 77.0983° W
8516990 | Willets Point, Little Bay, East River, New York | Ref | 40.7933° N | 73.7817° W
8516990 | Willets Point, Little Bay, East River, New York (sub) | Sub | 40.7933° N | 73.7817° W
9452391 | William Henry Bay, Lynn Canal, Alaska | Sub | 58.7133° N | 135.2320° W
ACT3446_1 | Williamsburg Bridge, 0.3 mile north of, East River, New York Current | Sub | 40.7180° N | 73.9707° W
8518699 | Williamsburg Bridge, East River, New York | Ref | 40.7117° N | 73.9683° W
8518699 | Williamsburg Bridge, East River, New York (sub) | Sub | 40.7117° N | 73.9683° W
ACT7151_1 | Williman Creek (Depth 10ft), South Carolina Current | Sub | 32.5617° N | 80.5917° W
ACT3481_1 | Willis Ave. Bridge, 0.1 mile NW of, Harlem River, New York Current | Sub | 40.8050° N | 73.9300° W
9452586 | Willoughby Island, Glacier Bay, Alaska | Sub | 58.6083° N | 136.1170° W
8666367 | Willtown Bluff, Edisto River, South Edisto River, South Carolina | Sub | 32.6817° N | 80.4167° W
8658559 | Wilmington Beach, North Carolina | Sub | 34.0317° N | 77.8933° W
ACT7451_1 | Wilmington Island, SSE of, Bull River (Depth 10ft), Wassaw Sound, Georgia Current | Sub | 31.9667° N | 80.9300° W
8550714 | Wilmington Marine Terminal, Christina River, Delaware | Sub | 39.7183° N | 75.5200° W
ACT7401_1 | Wilmington R. ent., south channel, Savannah River, Georgia Current | Sub | 32.0767° N | 81.0017° W
ACT7481_1 | Wilmington R., 0.5 mi. S of Turners Creek, Wassaw Sound, Georgia Current | Sub | 32.0050° N | 81.0033° W
ACT7471_1 | Wilmington River ent. off Cabbage Island, Wassaw Sound, Georgia Current | Sub | 31.9383° N | 80.9767° W
8658120 | Wilmington, North Carolina | Ref | 34.2275° N | 77.9536° W
8417553 | Wilson Cove, Middle Bay, Casco Bay, Maine | Sub | 43.8250° N | 69.9767° W
9410032 | Wilson Cove, San Clemente Island, California | Ref | 33.0050° N | 118.5570° W
TWC1683 | Windfall Harbor, Seymour Canal, Alaska | Sub | 57.8667° N | 134.2667° W
9451962 | Windham Bay, Alaska | Sub | 57.5433° N | 133.4980° W
8636623 | Windmill Point Light, Chesapeake Bay, Virginia | Sub | 37.5967° N | 76.2367° W
8636580 | Windmill Point, Rappahannock River, Virginia | Ref | 37.6161° N | 76.2900° W
8636580 | Windmill Point, Rappahannock River, Virginia (sub) | Sub | 37.6161° N | 76.2900° W
8662953 | Windsor Plantation, Black River, Great Pee Dee River, South Carolina | Ref | 33.4150° N | 79.2500° W
8667101 | Windsor Plantation, Russel Creek, North Edisto River, South Carolina | Sub | 32.5983° N | 80.3450° W
TWC1881 | Windy Bay, Hawkins Island, Prince William Sound, Alaska | Sub | 60.5667° N | 145.9667° W
9450251 | Windy Cove entrance, Alaska | Ref | 55.0354° N | 133.0238° W
8762850 | Wine Island, Terrebonne Bay, Louisiana | Sub | 29.0783° N | 90.5867° W
8661593 | Winea Plantation, Black River, Great Pee Dee River, South Carolina | Sub | 33.5350° N | 79.3883° W
TWC1863 | Wingham Island, Controller Bay, Alaska | Sub | 60.0500° N | 144.4000° W
PCT4436_1 | Wingham Island, off northeast corner, Controller Bay, Alaska Current | Sub | 60.0500° N | 144.3833° W
9415447 | Wingo, Sonoma Creek, San Pablo Bay, California | Sub | 38.2100° N | 122.4270° W
8413079 | Winter Harbor, Frenchman Bay, Maine | Sub | 44.3883° N | 68.0867° W
ACT8051_1 | Winter Point, St. Johns River, Florida Current | Sub | 30.3083° N | 81.6750° W
8414781 | Winterport, Penobscot River, Maine | Sub | 44.6367° N | 68.8417° W
TEC2929 | Winyah Bay Entrance (South Jetty), South Carolina | Sub | 33.1833° N | 79.1500° W
ACT6531_1 | Winyah Bay entrance, Winyah Bay, South Carolina Current | Sub | 33.2072° N | 79.1845° W
8416921 | Wiscasset, Sheepscot River, Maine | Ref | 44.0000° N | 69.6667° W
8416921 | Wiscasset, Sheepscot River, Maine (sub) | Sub | 44.0000° N | 69.6667° W
8630371 | Wishart Point, Bogues Bay, Virginia | Sub | 37.8817° N | 75.4917° W
8727395 | Withlacoochee River entrance, Florida | Sub | 29.0017° N | 82.7583° W
TEC3491 | Wolf Island, south end, Georgia | Sub | 31.3333° N | 81.3167° W
8748038 | Wolf River, Henderson Avenue bridge, Mississippi | Sub | 30.3583° N | 89.2733° W
8637144 | Wolf Trap Light, Chesapeake Bay, Virginia | Sub | 37.3900° N | 76.1900° W
8531156 | Woodbridge Creek, 0.8 n.mi. above entrance, Arthur Kill, New Jersey | Sub | 40.5450° N | 74.2650° W
8538548 | Woodbury Creek, New Jersey | Sub | 39.8600° N | 75.1867° W
9454562 | Wooded Islands, Montague Island, Alaska | Ref | 59.8750° N | 147.4030° W
9454562 | Wooded Islands, Montague Island, Alaska (sub) | Sub | 59.8750° N | 147.4030° W
8553501 | Woodland Beach, Delaware River, Delaware | Sub | 39.3333° N | 75.4667° W
8729736 | Woodlawn Beach, Florida | Ref | 30.3867° N | 86.9917° W
8516745 | Woodmere, Brosewere Bay, Hempstead Bay, New York | Sub | 40.6200° N | 73.6983° W
8447930 | Woods Hole, Buzzards Bay, Massachusetts | Ref | 41.5236° N | 70.6711° W
ACT6846_1 | Woods Point, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.9317° N | 79.9383° W
ACT6841_1 | Woods Point, SE of, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.9258° N | 79.9328° W
8664582 | Woodville, Wando River, South Carolina | Sub | 32.9200° N | 79.7333° W
PCT1186_1 | Woody Island Channel (Depth 15ft), Washington Current | Sub | 46.2395° N | 123.6733° W
PCT1191_1 | Woody Island Channel (off Seal Island) (Depth 12ft), Oregon Current | Sub | 46.2175° N | 123.6292° W
8571807 | Woolford, Church Creek, Little Choptank River, Maryland | Sub | 38.5067° N | 76.1733° W
8517251 | Worlds Fair Marina, Flushing Bay, New York | Ref | 40.7610° N | 73.8504° W
8573442 | Worton Creek entrance, Chesapeake Bay, Maryland | Sub | 39.2967° N | 76.1717° W
ACT5116_1 | Worton Point, 1.1 miles northwest of, Chesapeake Bay, Maryland Current | Sub | 39.3317° N | 76.2000° W
ACT5111_1 | Worton Point, 1.5 n.mi. WSW of (Depth 17ft), Chesapeake Bay, Maryland Current | Sub | 39.3117° N | 76.2172° W
TPT2715 | Wotje Atoll, Marshall Islands | Sub | 9.4667° N | 170.2333° E
PCT3131_1 | Wrangell Harbor, 1.6 miles west of, Zimovia Strait, Alaska Current | Sub | 56.4667° N | 132.4500° W
SEA0103_8 | Wrangell Narrows (off Petersburg), Alaska Current (6d) | Ref | 56.8163° N | 132.9640° W
9451204 | Wrangell, Wrangell Island, Alaska | Ref | 56.4700° N | 132.3870° W
9451204 | Wrangell, Wrangell Island, Alaska (sub) | Sub | 56.4700° N | 132.3870° W
ACT1761_1 | Wreck Shoal-Eldridge Shoal, between, Nantucket Sound, Massachusetts Current | Sub | 41.5333° N | 70.4283° W
8638441 | Wright Island Landing, Chickahominy River, Virginia | Sub | 37.3450° N | 76.8750° W
ACT7326_1 | Wright R., 0.2 mile above Walls Cut, South Carolina Current | Sub | 32.0850° N | 80.9217° W
8658163 | Wrightsville Beach, North Carolina | Ref | 34.2133° N | 77.7867° W
8658163 | Wrightsville Beach, North Carolina (sub) | Sub | 34.2133° N | 77.7867° W
8447506 | Wychmere Harbor, Nantucket Sound, Massachusetts | Sub | 41.6650° N | 70.0650° W
ACT6081_1 | Wye River, west of Bruffs Island (Depth 9ft), Eastern Bay, Maryland Current | Sub | 38.8547° N | 76.1980° W
PCT4211_1 | Wyvill Reef, Neva Strait, Alaska Current | Sub | 57.2667° N | 135.5833° W
9754228 | Yabucoa Harbor, Puerto Rico | Ref | 18.0551° N | 65.8330° W
8723776 | Yacht Harbor, Cowpens Anchorage, Plantation Key, Florida | Sub | 24.9650° N | 80.5683° W
9453220 | Yakutat, Yakutat Bay, Alaska | Ref | 59.5485° N | 139.7334° W
9453220 | Yakutat, Yakutat Bay, Alaska (sub) | Sub | 59.5485° N | 139.7334° W
8461467 | Yale boathouse, Thames River, Connecticut | Sub | 41.4300° N | 72.0933° W
8722784 | Yamato, ICWW, Florida | Sub | 26.4033° N | 80.0700° W
PCT1076_1 | Yaquina Bay entrance, Yaquina Bay, Oregon Current | Sub | 44.6167° N | 124.0667° W
PCT1091_1 | Yaquina River, 1 mile below Toledo, Yaquina Bay, Oregon Current | Sub | 44.6005° N | 123.9417° W
9435385 | Yaquina USCG station, Newport, Yaquina Bay, Oregon | Sub | 44.6267° N | 124.0550° W
PCT1086_1 | Yaquina, Yaquina River, Yaquina Bay, Oregon Current | Sub | 44.6020° N | 124.0113° W
8661093 | Yauhannah Bridge, Great Pee Dee River, South Carolina | Sub | 33.6600° N | 79.1550° W
8664541 | Yeamans Hall, Goose Creek, Cooper River, South Carolina | Sub | 32.9250° N | 79.9867° W
ACT6831_1 | Yellow House Creek, Cooper River, Charleston Harbor, South Carolina Current | Sub | 32.9088° N | 79.9363° W
ACT6836_1 | Yellow House Landing, 1 mile NW of, Cooper River, South Carolina Current | Sub | 32.9197° N | 79.9305° W
9414782 | Yerba Buena Island, San Francisco Bay, California | Sub | 37.8100° N | 122.3600° W
9450836 | Yes Cannery, Yes Bay, Alaska | Sub | 55.9133° N | 131.7970° W
PCT1951_1 | Yokeko Point, Deception Pass, Rosario Strait, Washington Current | Sub | 48.4128° N | 122.6137° W
9448601 | Yokeko Point, Deception Pass, Washington | Ref | 48.4133° N | 122.6150° W
9448601 | Yokeko Point, Deception Pass, Washington (sub) | Sub | 48.4133° N | 122.6150° W
9446705 | Yoman Point, Anderson Island, Balch Passage, Puget Sound, Washington | Ref | 47.1800° N | 122.6750° W
8666217 | Yonges Island, Wadmalaw River, South Carolina | Sub | 32.6950° N | 80.2233° W
8419518 | York Harbor, Maine | Sub | 43.1317° N | 70.6417° W
8637689 | Yorktown USCG Training Center, York River, Virginia | Ref | 37.2265° N | 76.4788° W
8637689 | Yorktown USCG Training Center, York River, Virginia (sub) | Sub | 37.2265° N | 76.4788° W
9452249 | Young Bay, Alaska | Sub | 58.1833° N | 134.5870° W
PCT3116_1 | Young Rock, 2 miles south of, Zimovia Strait, Alaska Current | Sub | 56.3333° N | 132.3833° W
PCT1146_1 | Youngs Bay Bridge (Depth 9ft), Oregon Current | Sub | 46.1778° N | 123.8683° W
9457648 | Zachar Bay, Uyak Bay, Alaska | Sub | 57.5483° N | 153.7350° W
9459465 | Zachary Bay, Unga Island, Shumagin Islands, Alaska | Ref | 55.3350° N | 160.6170° W
9463885 | Zapadni Bay, St. George Island, Alaska | Ref | 56.5700° N | 169.7000° W
TWC2375 | Zapadni Bay, St. George Island, Bering Sea, Alaska | Sub | 56.5667° N | 169.6833° W
8658741 | Zekes Island, Cape Fear River, North Carolina | Ref | 33.9500° N | 77.9517° W
9445269 | Zelatched Point, Dabob Bay, Washington | Sub | 47.7117° N | 122.8220° W


Network Working Group F. Dawson Request for Comments: 2445 Lotus Category: Standards Track D. Stenerson Microsoft November 1998 (as amended 2004-01-07, incorporating errata) Internet Calendaring and Scheduling Core Object Specification (iCalendar) Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1998). All Rights Reserved. Abstract There is a clear need to provide and deploy interoperable calendaring and scheduling services for the Internet. Current group scheduling and Personal Information Management (PIM) products are being extended for use across the Internet, today, in proprietary ways. This memo has been defined to provide the definition of a common format for openly exchanging calendaring and scheduling information across the Internet. This memo is formatted as a registration for a MIME media type per [RFC 2048]. However, the format in this memo is equally applicable for use outside of a MIME message content type. The proposed media type value is 'text/calendar'. This string would label a media type containing calendaring and scheduling information encoded as text characters formatted in a manner outlined below. This MIME media type provides a standard content type for capturing calendar event, to-do and journal entry information. It also can be used to convey free/busy time information. The content type is suitable as a MIME message entity that can be transferred over MIME based email systems, using HTTP or some other Internet transport. In Dawson & Stenerson Standards Track [Page 1] RFC 2445 iCalendar November 1998 addition, the content type is useful as an object for interactions between desktop applications using the operating system clipboard, drag/drop or file systems capabilities. This memo is based on the earlier work of the vCalendar specification for the exchange of personal calendaring and scheduling information. In order to avoid confusion with this referenced work, this memo is to be known as the iCalendar specification. This memo defines the format for specifying iCalendar object methods. An iCalendar object method is a set of usage constraints for the iCalendar object. For example, these methods might define scheduling messages that request an event be scheduled, reply to an event request, send a cancellation notice for an event, modify or replace the definition of an event, provide a counter proposal for an original event request, delegate an event request to another individual, request free or busy time, reply to a free or busy time request, or provide similar scheduling messages for a to-do or journal entry calendar component. The iCalendar Transport-indendent Interoperability Protocol (iTIP) defined in [ITIP] is one such scheduling protocol. Table of Contents 1 Introduction.....................................................5 2 Basic Grammar and Conventions....................................6 2.1 Formatting Conventions .......................................7 2.2 Related Memos ................................................8 2.3 International Considerations .................................8 3 Registration Information.........................................8 3.1 Content Type .................................................8 3.2 Parameters ...................................................9 3.3 Content Header Fields .......................................10 3.4 Encoding Considerations .....................................10 3.5 Security Considerations .....................................10 3.6 Interoperability Considerations .............................11 3.7 Applications Which Use This Media Type ......................11 3.8 Additional Information ......................................11 3.9 Magic Numbers ...............................................11 3.10 File Extensions ............................................11 3.11 Contact for Further Information: ...........................12 3.12 Intended Usage .............................................12 3.13 Authors/Change Controllers .................................12 4 iCalendar Object Specification..................................13 4.1 Content Lines ...............................................13 4.1.1 List and Field Separators ................................16 4.1.2 Multiple Values ..........................................16 4.1.3 Binary Content ...........................................16 Dawson & Stenerson Standards Track [Page 2] RFC 2445 iCalendar November 1998 4.1.4 Character Set ............................................17 4.2 Property Parameters .........................................17 4.2.1 Alternate Text Representation ............................18 4.2.2 Common Name ..............................................19 4.2.3 Calendar User Type .......................................20 4.2.4 Delegators ...............................................20 4.2.5 Delegatees ...............................................21 4.2.6 Directory Entry Reference ................................21 4.2.7 Inline Encoding ..........................................22 4.2.8 Format Type ..............................................23 4.2.9 Free/Busy Time Type ......................................23 4.2.10 Language ................................................24 4.2.11 Group or List Membership ................................25 4.2.12 Participation Status ....................................25 4.2.13 Recurrence Identifier Range .............................27 4.2.14 Alarm Trigger Relationship ..............................27 4.2.15 Relationship Type .......................................28 4.2.16 Participation Role ......................................29 4.2.17 RSVP Expectation ........................................29 4.2.18 Sent By .................................................30 4.2.19 Time Zone Identifier ....................................30 4.2.20 Value Data Types ........................................32 4.3 Property Value Data Types ...................................32 4.3.1 Binary ...................................................33 4.3.2 Boolean ..................................................33 4.3.3 Calendar User Address ....................................34 4.3.4 Date .....................................................34 4.3.5 Date-Time ................................................35 4.3.6 Duration .................................................37 4.3.7 Float ....................................................38 4.3.8 Integer ..................................................38 4.3.9 Period of Time ...........................................39 4.3.10 Recurrence Rule .........................................40 4.3.11 Text ....................................................45 4.3.12 Time ....................................................47 4.3.13 URI .....................................................49 4.3.14 UTC Offset ..............................................49 4.4 iCalendar Object ............................................50 4.5 Property ....................................................51 4.6 Calendar Components .........................................51 4.6.1 Event Component ..........................................52 4.6.2 To-do Component ..........................................55 4.6.3 Journal Component ........................................56 4.6.4 Free/Busy Component ......................................58 4.6.5 Time Zone Component ......................................60 4.6.6 Alarm Component ..........................................67 4.7 Calendar Properties .........................................73 4.7.1 Calendar Scale ...........................................73 Dawson & Stenerson Standards Track [Page 3] RFC 2445 iCalendar November 1998 4.7.2 Method ...................................................74 4.7.3 Product Identifier .......................................75 4.7.4 Version ..................................................76 4.8 Component Properties ........................................77 4.8.1 Descriptive Component Properties .........................77 4.8.1.1 Attachment ...........................................77 4.8.1.2 Categories ...........................................78 4.8.1.3 Classification .......................................79 4.8.1.4 Comment ..............................................80 4.8.1.5 Description ..........................................81 4.8.1.6 Geographic Position ..................................82 4.8.1.7 Location .............................................84 4.8.1.8 Percent Complete .....................................85 4.8.1.9 Priority .............................................85 4.8.1.10 Resources ...........................................87 4.8.1.11 Status ..............................................88 4.8.1.12 Summary .............................................89 4.8.2 Date and Time Component Properties .......................90 4.8.2.1 Date/Time Completed ..................................90 4.8.2.2 Date/Time End ........................................91 4.8.2.3 Date/Time Due ........................................92 4.8.2.4 Date/Time Start ......................................93 4.8.2.5 Duration .............................................94 4.8.2.6 Free/Busy Time .......................................95 4.8.2.7 Time Transparency ....................................96 4.8.3 Time Zone Component Properties ...........................97 4.8.3.1 Time Zone Identifier .................................97 4.8.3.2 Time Zone Name .......................................98 4.8.3.3 Time Zone Offset From ................................99 4.8.3.4 Time Zone Offset To .................................100 4.8.3.5 Time Zone URL .......................................101 4.8.4 Relationship Component Properties .......................102 4.8.4.1 Attendee ............................................102 4.8.4.2 Contact .............................................104 4.8.4.3 Organizer ...........................................106 4.8.4.4 Recurrence ID .......................................107 4.8.4.5 Related To ..........................................109 4.8.4.6 Uniform Resource Locator ............................110 4.8.4.7 Unique Identifier ...................................111 4.8.5 Recurrence Component Properties .........................112 4.8.5.1 Exception Date/Times ................................112 4.8.5.2 Exception Rule ......................................114 4.8.5.3 Recurrence Date/Times ...............................115 4.8.5.4 Recurrence Rule .....................................117 4.8.6 Alarm Component Properties ..............................126 4.8.6.1 Action ..............................................126 4.8.6.2 Repeat Count ........................................126 4.8.6.3 Trigger .............................................127 Dawson & Stenerson Standards Track [Page 4] RFC 2445 iCalendar November 1998 4.8.7 Change Management Component Properties ..................129 4.8.7.1 Date/Time Created ...................................129 4.8.7.2 Date/Time Stamp .....................................130 4.8.7.3 Last Modified .......................................131 4.8.7.4 Sequence Number .....................................131 4.8.8 Miscellaneous Component Properties ......................133 4.8.8.1 Non-standard Properties .............................133 4.8.8.2 Request Status ......................................134 5 iCalendar Object Examples......................................136 6 Recommended Practices..........................................140 7 Registration of Content Type Elements..........................141 7.1 Registration of New and Modified iCalendar Object Methods ..141 7.2 Registration of New Properties .............................141 7.2.1 Define the property .....................................142 7.2.2 Post the Property definition ............................143 7.2.3 Allow a comment period ..................................143 7.2.4 Submit the property for approval ........................143 7.3 Property Change Control ....................................143 8 References.....................................................144 9 Acknowledgments................................................145 10 Authors' and Chairs' Addresses................................146 11 Full Copyright Statement......................................148 1 Introduction The use of calendaring and scheduling has grown considerably in the last decade. Enterprise and inter-enterprise business has become dependent on rapid scheduling of events and actions using this information technology. However, the longer term growth of calendaring and scheduling, is currently limited by the lack of Internet standards for the message content types that are central to these knowledgeware applications. This memo is intended to progress the level of interoperability possible between dissimilar calendaring and scheduling applications. This memo defines a MIME content type for exchanging electronic calendaring and scheduling information. The Internet Calendaring and Scheduling Core Object Specification, or iCalendar, allows for the capture and exchange of information normally stored within a calendaring and scheduling application; such as a Personal Information Manager (PIM) or a Group Scheduling product. The iCalendar format is suitable as an exchange format between applications or systems. The format is defined in terms of a MIME content type. This will enable the object to be exchanged using several transports, including but not limited to SMTP, HTTP, a file system, desktop interactive protocols such as the use of a memory- based clipboard or drag/drop interactions, point-to-point asynchronous communication, wired-network transport, or some form of Dawson & Stenerson Standards Track [Page 5] RFC 2445 iCalendar November 1998 unwired transport such as infrared might also be used. The memo also provides for the definition of iCalendar object methods that will map this content type to a set of messages for supporting calendaring and scheduling operations such as requesting, replying to, modifying, and canceling meetings or appointments, to-dos and journal entries. The iCalendar object methods can be used to define other calendaring and scheduling operations such a requesting for and replying with free/busy time data. Such a scheduling protocol is defined in the iCalendar Transport-independent Interoperability Protocol (iTIP) defined in [ITIP]. The memo also includes a formal grammar for the content type based on the Internet ABNF defined in [RFC 2234]. This ABNF is required for the implementation of parsers and to serve as the definitive reference when ambiguities or questions arise in interpreting the descriptive prose definition of the memo. 2 Basic Grammar and Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interoperated as described in [RFC 2119]. This memo makes use of both a descriptive prose and a more formal notation for defining the calendaring and scheduling format. The notation used in this memo is the ABNF notation of [RFC 2234]. Readers intending on implementing this format defined in this memo should be familiar with this notation in order to properly interpret the specifications of this memo. All numeric and hexadecimal values used in this memo are given in decimal notation. All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated. Note: All indented editorial notes, such as this one, are intended to provide the reader with additional information. The information is not essential to the building of an implementation conformant with this memo. The information is provided to highlight a particular feature or characteristic of the memo. Dawson & Stenerson Standards Track [Page 6] RFC 2445 iCalendar November 1998 The format for the iCalendar object is based on the syntax of the [RFC 2425] content type. While the iCalendar object is not a profile of the [RFC 2425] content type, it does reuse a number of the elements from the [RFC 2425] specification. 2.1 Formatting Conventions The mechanisms defined in this memo are defined in prose. Many of the terms used to describe these have common usage that is different than the standards usage of this memo. In order to reference within this memo elements of the calendaring and scheduling model, core object (this memo) or interoperability protocol [ITIP] some formatting conventions have been used. Calendaring and scheduling roles are referred to in quoted-strings of text with the first character of each word in upper case. For example, "Organizer" refers to a role of a "Calendar User" within the scheduling protocol defined by [ITIP]. Calendar components defined by this memo are referred to with capitalized, quoted-strings of text. All calendar components start with the letter "V". For example, "VEVENT" refers to the event calendar component, "VTODO" refers to the to-do calendar component and "VJOURNAL" refers to the daily journal calendar component. Scheduling methods defined by [ITIP] are referred to with capitalized, quoted-strings of text. For example, "REQUEST" refers to the method for requesting a scheduling calendar component be created or modified, "REPLY" refers to the method a recipient of a request uses to update their status with the "Organizer" of the calendar component. The properties defined by this memo are referred to with capitalized, quoted-strings of text, followed by the word "property". For example, "ATTENDEE" property refers to the iCalendar property used to convey the calendar address of a calendar user. Property parameters defined by this memo are referred to with lowercase, quoted-strings of text, followed by the word "parameter". For example, "value" parameter refers to the iCalendar property parameter used to override the default data type for a property value. Enumerated values defined by this memo are referred to with capitalized text, either alone or followed by the word "value". For example, the "MINUTELY" value can be used with the "FREQ" component of the "RECUR" data type to specify repeating components based on an interval of one minute or more. Dawson & Stenerson Standards Track [Page 7] RFC 2445 iCalendar November 1998 2.2 Related Memos Implementers will need to be familiar with several other memos that, along with this memo, form a framework for Internet calendaring and scheduling standards. This memo, [ICAL], specifies a core specification of objects, data types, properties and property parameters. [ITIP] - specifies an interoperability protocol for scheduling between different implementations; [IMIP] specifies an Internet email binding for [ITIP]. This memo does not attempt to repeat the specification of concepts or definitions from these other memos. Where possible, references are made to the memo that provides for the specification of these concepts or definitions. 2.3 International Considerations In the rest of this document, descriptions of characters are of the form "character name (codepoint)", where "codepoint" is from the US- ASCII character set. The "character name" is the authoritative description; (codepoint) is a reference to that character in US-ASCII or US-ASCII compatible sets (for example the ISO-8859-x family, UTF- 8, ISO-2022-xx, KOI8-R). If a non-US-ASCII compatible character set is used, appropriate code-point from that character set MUST be chosen instead. Use of non-US-ASCII-compatible character sets is NOT recommended. 3 Registration Information The Calendaring and Scheduling Core Object Specification is intended for use as a MIME content type. However, the implementation of the memo is in no way limited solely as a MIME content type. 3.1 Content Type The following text is intended to register this memo as the MIME content type "text/calendar". To: ietf-types@uninett.no Subject: Registration of MIME content type text/calendar. MIME media type name: text MIME subtype name: calendar Dawson & Stenerson Standards Track [Page 8] RFC 2445 iCalendar November 1998 3.2 Parameters Required parameters: none Optional parameters: charset, method, component and optinfo The "charset" parameter is defined in [RFC 2046] for other body parts. It is used to identify the default character set used within the body part. The "method" parameter is used to convey the iCalendar object method or transaction semantics for the calendaring and scheduling information. It also is an identifier for the restricted set of properties and values that the iCalendar object consists of. The parameter is to be used as a guide for applications interpreting the information contained within the body part. It SHOULD NOT be used to exclude or require particular pieces of information unless the identified method definition specifically calls for this behavior. Unless specifically forbidden by a particular method definition, a text/calendar content type can contain any set of properties permitted by the Calendaring and Scheduling Core Object Specification. The "method" parameter MUST be the same value as that specified in the "METHOD" component property in the iCalendar object. If one is present, the other MUST also be present. The value for the "method" parameter is defined as follows: method = 1*(ALPHA / DIGIT / "-") ; IANA registered iCalendar object method The "component" parameter conveys the type of iCalendar calendar component within the body part. If the iCalendar object contains more than one calendar component type, then multiple component parameters MUST be specified. The value for the "component" parameter is defined as follows: component = ("VEVENT" / "VTODO" / "VJOURNAL" / "VFREEBUSY" / "VTIMEZONE" / x-name / iana-token) The "optinfo" parameter conveys optional information about the iCalendar object within the body part. This parameter can only specify semantics already specified by the iCalendar object and that can be otherwise determined by parsing the body part. In addition, the optional information specified by this parameter MUST be consistent with that information specified by the iCalendar object. For example, it can be used to convey the "Attendee" response status to a meeting request. The parameter value consists of a string value. Dawson & Stenerson Standards Track [Page 9] RFC 2445 iCalendar November 1998 The parameter can be specified multiple times. This parameter MAY only specify semantics already specified by the iCalendar object and that can be otherwise determined by parsing the body part. The value for the "optinfo" parameter is defined as follows: optinfo = infovalue / qinfovalue infovalue = iana-token / x-name qinfovalue = DQUOTE (infovalue) DQUOTE 3.3 Content Header Fields Optional content header fields: Any header fields defined by [RFC 2045]. 3.4 Encoding Considerations This MIME content type can contain 8bit characters, so the use of quoted-printable or BASE64 MIME content-transfer-encodings might be necessary when iCalendar objects are transferred across protocols restricted to the 7bit repertoire. Note that a text valued property in the content entity can also have content encoding of special characters using a BACKSLASH character (US-ASCII decimal 92) escapement technique. This means that content values can end up encoded twice. 3.5 Security Considerations SPOOFING - - In this memo, the "Organizer" is the only person authorized to make changes to an existing "VEVENT", "VTODO", "VJOURNAL" calendar component and redistribute the updates to the "Attendees". An iCalendar object that maliciously changes or cancels an existing "VEVENT", "VTODO" or "VJOURNAL" or "VFREEBUSY" calendar component might be constructed by someone other than the "Organizer" and sent to the "Attendees". In addition in this memo, other than the "Organizer", an "Attendee" of a "VEVENT", "VTODO", "VJOURNAL" calendar component is the only other person authorized to update any parameter associated with their "ATTENDEE" property and send it to the "Organizer". An iCalendar object that maliciously changes the "ATTENDEE" parameters can be constructed by someone other than the real "Attendee" and sent to the "Organizer". Dawson & Stenerson Standards Track [Page 10] RFC 2445 iCalendar November 1998 PROCEDURAL ALARMS - - An iCalendar object can be created that contains a "VEVENT" and "VTODO" calendar component with "VALARM" calendar components. The "VALARM" calendar component can be of type PROCEDURE and can have an attachment containing some sort of executable program. Implementations that incorporate these types of alarms are subject to any virus or malicious attack that might occur as a result of executing the attachment. ATTACHMENTS - - An iCalendar object can include references to Uniform Resource Locators that can be programmed resources. Implementers and users of this memo should be aware of the network security implications of accepting and parsing such information. In addition, the security considerations observed by implementations of electronic mail systems should be followed for this memo. 3.6 Interoperability Considerations This MIME content type is intended to define a common format for conveying calendaring and scheduling information between different systems. It is heavily based on the earlier [VCAL] industry specification. 3.7 Applications Which Use This Media Type This content-type is designed for widespread use by Internet calendaring and scheduling applications. In addition, applications in the workflow and document management area might find this content- type applicable. The [ITIP] and [IMIP] Internet protocols directly use this content-type also. Future work on an Internet calendar access protocol will utilize this content-type too. 3.8 Additional Information This memo defines this content-type. 3.9 Magic Numbers None. 3.10 File Extensions The file extension of "ics" is to be used to designate a file containing (an arbitrary set of) calendaring and scheduling information consistent with this MIME content type. Dawson & Stenerson Standards Track [Page 11] RFC 2445 iCalendar November 1998 The file extension of "ifb" is to be used to designate a file containing free or busy time information consistent with this MIME content type. Macintosh file type codes: The file type code of "iCal" is to be used in Apple MacIntosh operating system environments to designate a file containing calendaring and scheduling information consistent with this MIME media type. The file type code of "iFBf" is to be used in Apple MacIntosh operating system environments to designate a file containing free or busy time information consistent with this MIME media type. 3.11 Contact for Further Information: Frank Dawson 6544 Battleford Drive Raleigh, NC 27613-3502 919-676-9515 (Telephone) 919-676-9564 (Data/Facsimile) Frank_Dawson@Lotus.com (Internet Mail) Derik Stenerson One Microsoft Way Redmond, WA 98052-6399 425-936-5522 (Telephone) 425-936-7329 (Facsimile) deriks@microsoft.com (Internet Mail) 3.12 Intended Usage COMMON 3.13 Authors/Change Controllers Frank Dawson 6544 Battleford Drive Raleigh, NC 27613-3502 919-676-9515 (Telephone) 919-676-9564 (Data/Facsimile) Frank_Dawson@Lotus.com (Internet Mail) Derik Stenerson One Microsoft Way Redmond, WA 98052-6399 425-936-5522 (Telephone) 425-936-7329 (Facsimile) deriks@microsoft.com (Internet Mail) Dawson & Stenerson Standards Track [Page 12] RFC 2445 iCalendar November 1998 4 iCalendar Object Specification The following sections define the details of a Calendaring and Scheduling Core Object Specification. This information is intended to be an integral part of the MIME content type registration. In addition, this information can be used independent of such content registration. In particular, this memo has direct applicability for use as a calendaring and scheduling exchange format in file-, memory- or network-based transport mechanisms. 4.1 Content Lines The iCalendar object is organized into individual lines of text, called content lines. Content lines are delimited by a line break, which is a CRLF sequence (US-ASCII decimal 13, followed by US-ASCII decimal 10). Lines of text SHOULD NOT be longer than 75 octets, excluding the line break. Long content lines SHOULD be split into a multiple line representations using a line "folding" technique. That is, a long line can be split between any two characters by inserting a CRLF immediately followed by a single linear white space character (i.e., SPACE, US-ASCII decimal 32 or HTAB, US-ASCII decimal 9). Any sequence of CRLF followed immediately by a single linear white space character is ignored (i.e., removed) when processing the content type. For example the line: DESCRIPTION:This is a long description that exists on a long line. Can be represented as: DESCRIPTION:This is a lo ng description that exists on a long line. The process of moving from this folded multiple line representation to its single line representation is called "unfolding". Unfolding is accomplished by removing the CRLF character and the linear white space character that immediately follows. When parsing a content line, folded lines MUST first be unfolded according to the unfolding procedure described above. When generating a content line, lines longer than 75 octets SHOULD be folded according to the folding procedure described above. Dawson & Stenerson Standards Track [Page 13] RFC 2445 iCalendar November 1998 The content information associated with an iCalendar object is formatted using a syntax similar to that defined by [RFC 2425]. That is, the content information consists of CRLF-separated content lines. The following notation defines the lines of content in an iCalendar object: contentline = name *(";" param ) ":" value CRLF ; This ABNF is just a general definition for an initial parsing ; of the content line into its property name, parameter list, ; and value string ; When parsing a content line, folded lines MUST first ; be unfolded according to the unfolding procedure ; described above. When generating a content line, lines ; longer than 75 octets SHOULD be folded according to ; the folding procedure described above. name = x-name / iana-token iana-token = 1*(ALPHA / DIGIT / "-") ; iCalendar identifier registered with IANA x-name = "X-" [vendorid "-"] 1*(ALPHA / DIGIT / "-") ; Reservered for experimental use. Not intended for use in ; released products. vendorid = 3*(ALPHA / DIGIT) ;Vendor identification param = param-name "=" param-value *("," param-value) ; Each property defines the specific ABNF for the parameters ; allowed on the property. Refer to specific properties for ; precise parameter ABNF. param-name = iana-token / x-token param-value = paramtext / quoted-string paramtext = *SAFE-CHAR value = *VALUE-CHAR quoted-string = DQUOTE *QSAFE-CHAR DQUOTE NON-US-ASCII = %x80-F8 ; Use restricted by charset parameter ; on outer MIME object (UTF-8 preferred) Dawson & Stenerson Standards Track [Page 14] RFC 2445 iCalendar November 1998 QSAFE-CHAR = WSP / %x21 / %x23-7E / NON-US-ASCII ; Any character except CTLs and DQUOTE SAFE-CHAR = WSP / %x21 / %x23-2B / %x2D-39 / %x3C-7E / NON-US-ASCII ; Any character except CTLs, DQUOTE, ";", ":", "," VALUE-CHAR = WSP / %x21-7E / NON-US-ASCII ; Any textual character CR = %x0D ; carriage return LF = %x0A ; line feed CRLF = CR LF ; Internet standard newline CTL = %x00-08 / %x0A-1F / %x7F ; Controls ALPHA = %x41-5A / %x61-7A ; A-Z / a-z DIGIT = %x30-39 ; 0-9 DQUOTE = %x22 ; Quotation Mark WSP = SPACE / HTAB SPACE = %x20 HTAB = %x09 The property value component of a content line has a format that is property specific. Refer to the section describing each property for a definition of this format. All names of properties, property parameters, enumerated property values and property parameter values are case-insensitive. However, all other property values are case-sensitive, unless otherwise stated. Dawson & Stenerson Standards Track [Page 15] RFC 2445 iCalendar November 1998 4.1.1 List and Field Separators Some properties and parameters allow a list of values. Values in a list of values MUST be separated by a COMMA character (US-ASCII decimal 44). There is no significance to the order of values in a list. For those parameter values (such as those that specify URI values) that are specified in quoted-strings, the individual quoted- strings are separated by a COMMA character (US-ASCII decimal 44). Some property values are defined in terms of multiple parts. These structured property values MUST have their value parts separated by a SEMICOLON character (US-ASCII decimal 59). Some properties allow a list of parameters. Each property parameter in a list of property parameters MUST be separated by a SEMICOLON character (US-ASCII decimal 59). Property parameters with values containing a COLON, a SEMICOLON or a COMMA character MUST be placed in quoted text. For example, in the following properties a SEMICOLON is used to separate property parameters from each other, and a COMMA is used to separate property values in a value list. ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT:MAILTO: jsmith@host.com RDATE;VALUE=DATE:19970304,19970504,19970704,19970904 4.1.2 Multiple Values Some properties defined in the iCalendar object can have multiple values. The general rule for encoding multi-valued items is to simply create a new content line for each value, including the property name. However, it should be noted that some properties support encoding multiple values in a single property by separating the values with a COMMA character (US-ASCII decimal 44). Individual property definitions should be consulted for determining whether a specific property allows multiple values and in which of these two forms. 4.1.3 Binary Content Binary content information in an iCalendar object SHOULD be referenced using a URI within a property value. That is the binary content information SHOULD be placed in an external MIME entity that can be referenced by a URI from within the iCalendar object. In applications where this is not feasible, binary content information Dawson & Stenerson Standards Track [Page 16] RFC 2445 iCalendar November 1998 can be included within an iCalendar object, but only after first encoding it into text using the "BASE64" encoding method defined in [RFC 2045]. Inline binary contact SHOULD only be used in applications whose special circumstances demand that an iCalendar object be expressed as a single entity. A property containing inline binary content information MUST specify the "ENCODING" property parameter. Binary content information placed external to the iCalendar object MUST be referenced by a uniform resource identifier (URI). The following example specifies an "ATTACH" property that references an attachment external to the iCalendar object with a URI reference: ATTACH:http://xyz.com/public/quarterly-report.doc The following example specifies an "ATTACH" property with inline binary encoded content information: ATTACH;FMTTYPE=image/basic;ENCODING=BASE64;VALUE=BINARY: MIICajCCAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1U EBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIE <...remainder of "BASE64" encoded binary data...> 4.1.4 Character Set There is not a property parameter to declare the character set used in a property value. The default character set for an iCalendar object is UTF-8 as defined in [RFC 2279]. The "charset" Content-Type parameter can be used in MIME transports to specify any other IANA registered character set. 4.2 Property Parameters A property can have attributes associated with it. These "property parameters" contain meta-information about the property or the property value. Property parameters are provided to specify such information as the location of an alternate text representation for a property value, the language of a text property value, the data type of the property value and other attributes. Property parameter values that contain the COLON (US-ASCII decimal 58), SEMICOLON (US-ASCII decimal 59) or COMMA (US-ASCII decimal 44) character separators MUST be specified as quoted-string text values. Property parameter values MUST NOT contain the DOUBLE-QUOTE (US-ASCII decimal 22) character. The DOUBLE-QUOTE (US-ASCII decimal 22) character is used as a delimiter for parameter values that contain restricted characters or URI text. For example: Dawson & Stenerson Standards Track [Page 17] RFC 2445 iCalendar November 1998 DESCRIPTION;ALTREP="http://www.wiz.org":The Fall'98 Wild Wizards Conference - - Las Vegas\, NV\, USA Property parameter values that are not in quoted strings are case insensitive. The general property parameters defined by this memo are defined by the following notation: parameter = altrepparam ; Alternate text representation / cnparam ; Common name / cutypeparam ; Calendar user type / delfromparam ; Delegator / deltoparam ; Delegatee / dirparam ; Directory entry / encodingparam ; Inline encoding / fmttypeparam ; Format type / fbtypeparam ; Free/busy time type / languageparam ; Language for text / memberparam ; Group or list membership / partstatparam ; Participation status / rangeparam ; Recurrence identifier range / trigrelparam ; Alarm trigger relationship / reltypeparam ; Relationship type / roleparam ; Participation role / rsvpparam ; RSVP expectation / sentbyparam ; Sent by / tzidparam ; Reference to time zone object / valuetypeparam ; Property value data type / ianaparam ; Some other IANA registered iCalendar parameter. / xparam ; A non-standard, experimental parameter. ianaparam = iana-token "=" param-value *("," param-value) xparam =x-name "=" param-value *("," param-value) 4.2.1 Alternate Text Representation Parameter Name: ALTREP Purpose: To specify an alternate text representation for the property value. Format Definition: The property parameter is defined by the following notation: Dawson & Stenerson Standards Track [Page 18] RFC 2445 iCalendar November 1998 altrepparam = "ALTREP" "=" DQUOTE uri DQUOTE Description: The parameter specifies a URI that points to an alternate representation for a textual property value. A property specifying this parameter MUST also include a value that reflects the default representation of the text value. The individual URI parameter values MUST each be specified in a quoted-string. Example: DESCRIPTION;ALTREP="CID:":Project XYZ Review Meeting will include the following agenda items: (a) Market Overview\, (b) Finances\, (c) Project Management The "ALTREP" property parameter value might point to a "text/html" content portion. Content-Type:text/html Content-Id:

Project XYZ Review Meeting will include the following agenda items:

  1. Market Overview
  2. Finances
  3. Project Management

4.2.2 Common Name Parameter Name: CN Purpose: To specify the common name to be associated with the calendar user specified by the property. Format Definition: The property parameter is defined by the following notation: cnparam = "CN" "=" param-value Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter specifies the common name to be associated with the calendar user specified by the property. The parameter value is text. The parameter value can be used for display text to be associated with the calendar address specified by the property. Dawson & Stenerson Standards Track [Page 19] RFC 2445 iCalendar November 1998 Example: ORGANIZER;CN="John Smith":MAILTO:jsmith@host.com 4.2.3 Calendar User Type Parameter Name: CUTYPE Purpose: To specify the type of calendar user specified by the property. Format Definition: The property parameter is defined by the following notation: cutypeparam = "CUTYPE" "=" ("INDIVIDUAL" ; An individual / "GROUP" ; A group of individuals / "RESOURCE" ; A physical resource / "ROOM" ; A room resource / "UNKNOWN" ; Otherwise not known / x-name ; Experimental type / iana-token) ; Other IANA registered ; type ; Default is INDIVIDUAL Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter identifies the type of calendar user specified by the property. If not specified on a property that allows this parameter, the default is INDIVIDUAL. Example: ATTENDEE;CUTYPE=GROUP:MAILTO:ietf-calsch@imc.org 4.2.4 Delegators Parameter Name: DELEGATED-FROM Purpose: To specify the calendar users that have delegated their participation to the calendar user specified by the property. Format Definition: The property parameter is defined by the following notation: delfromparam = "DELEGATED-FROM" "=" DQUOTE cal-address DQUOTE *("," DQUOTE cal-address DQUOTE) Dawson & Stenerson Standards Track [Page 20] RFC 2445 iCalendar November 1998 Description: This parameter can be specified on properties with a CAL-ADDRESS value type. This parameter can be specified on a property that has a value type of calendar address. This parameter specifies those calendar uses that have delegated their participation in a group scheduled event or to-do to the calendar user specified by the property. The value MUST be a MAILTO URI as defined in [RFC 1738]. The individual calendar address parameter values MUST each be specified in a quoted-string. Example: ATTENDEE;DELEGATED-FROM="MAILTO:jsmith@host.com":MAILTO: jdoe@host.com 4.2.5 Delegatees Parameter Name: DELEGATED-TO Purpose: To specify the calendar users to whom the calendar user specified by the property has delegated participation. Format Definition: The property parameter is defined by the following notation: deltoparam = "DELEGATED-TO" "=" DQUOTE cal-address DQUOTE *("," DQUOTE cal-address DQUOTE) Description: This parameter can be specified on properties with a CAL-ADDRESS value type. This parameter specifies those calendar users whom have been delegated participation in a group scheduled event or to-do by the calendar user specified by the property. The value MUST be a MAILTO URI as defined in [RFC 1738]. The individual calendar address parameter values MUST each be specified in a quoted-string. Example: ATTENDEE;DELEGATED-TO="MAILTO:jdoe@host.com","MAILTO:jqpublic@ host.com":MAILTO:jsmith@host.com 4.2.6 Directory Entry Reference Parameter Name: DIR Purpose: To specify reference to a directory entry associated with the calendar user specified by the property. Format Definition: The property parameter is defined by the following notation: Dawson & Stenerson Standards Track [Page 21] RFC 2445 iCalendar November 1998 dirparam = "DIR" "=" DQUOTE uri DQUOTE Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter specifies a reference to the directory entry associated with the calendar user specified by the property. The parameter value is a URI. The individual URI parameter values MUST each be specified in a quoted-string. Example: ORGANIZER;DIR="ldap://host.com:6666/o=eDABC%20Industries,c=3DUS?? (cn=3DBJim%20Dolittle)":MAILTO:jimdo@host1.com 4.2.7 Inline Encoding Parameter Name: ENCODING Purpose: To specify an alternate inline encoding for the property value. Format Definition: The property parameter is defined by the following notation: encodingparam = "ENCODING" "=" ("8BIT" ; "8bit" text encoding is defined in [RFC 2045] / "BASE64" ; "BASE64" binary encoding format is defined in [RFC 2045] / iana-token ; Some other IANA registered iCalendar encoding type / x-name) ; A non-standard, experimental encoding type Description: The property parameter identifies the inline encoding used in a property value. The default encoding is "8BIT", corresponding to a property value consisting of text. The "BASE64" encoding type corresponds to a property value encoded using the "BASE64" encoding defined in [RFC 2045]. If the value type parameter is ";VALUE=BINARY", then the inline encoding parameter MUST be specified with the value ";ENCODING=BASE64". Dawson & Stenerson Standards Track [Page 22] RFC 2445 iCalendar November 1998 Example: ATTACH;FMTYPE=IMAGE/JPEG;ENCODING=BASE64;VALUE=BINARY:MIICajC CAdOgAwIBAgICBEUwDQYJKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDA qBgNVBAoTI05ldHNjYXBlIENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRw <...remainder of "BASE64" encoded binary data...> 4.2.8 Format Type Parameter Name: FMTTYPE Purpose: To specify the content type of a referenced object. Format Definition: The property parameter is defined by the following notation: fmttypeparam = "FMTTYPE" "=" iana-token ; A IANA registered content type / x-name ; A non-standard content type Description: This parameter can be specified on properties that are used to reference an object. The parameter specifies the content type of the referenced object. For example, on the "ATTACH" property, a FTP type URI value does not, by itself, necessarily convey the type of content associated with the resource. The parameter value MUST be the TEXT for either an IANA registered content type or a non-standard content type. Example: ATTACH;FMTTYPE=application/binary:ftp://domain.com/pub/docs/ agenda.doc 4.2.9 Free/Busy Time Type Parameter Name: FBTYPE Purpose: To specify the free or busy time type. Format Definition: The property parameter is defined by the following notation: fbtypeparam = "FBTYPE" "=" ("FREE" / "BUSY" / "BUSY-UNAVAILABLE" / "BUSY-TENTATIVE" / x-name ; Some experimental iCalendar data type. / iana-token) Dawson & Stenerson Standards Track [Page 23] RFC 2445 iCalendar November 1998 ; Some other IANA registered iCalendar data type. Description: The parameter specifies the free or busy time type. The value FREE indicates that the time interval is free for scheduling. The value BUSY indicates that the time interval is busy because one or more events have been scheduled for that interval. The value BUSY-UNAVAILABLE indicates that the time interval is busy and that the interval can not be scheduled. The value BUSY-TENTATIVE indicates that the time interval is busy because one or more events have been tentatively scheduled for that interval. If not specified on a property that allows this parameter, the default is BUSY. Example: The following is an example of this parameter on a FREEBUSY property. FREEBUSY;FBTYPE=BUSY:19980415T133000Z/19980415T170000Z 4.2.10 Language Parameter Name: LANGUAGE Purpose: To specify the language for text values in a property or property parameter. Format Definition: The property parameter is defined by the following notation: languageparam = "LANGUAGE" "=" language language = Description: This parameter can be specified on properties with a text value type. The parameter identifies the language of the text in the property or property parameter value. The value of the "language" property parameter is that defined in [RFC 1766]. For transport in a MIME entity, the Content-Language header field can be used to set the default language for the entire body part. Otherwise, no default language is assumed. Example: SUMMARY;LANGUAGE=us-EN:Company Holiday Party LOCATION;LANGUAGE=en:Germany LOCATION;LANGUAGE=no:Tyskland Dawson & Stenerson Standards Track [Page 24] RFC 2445 iCalendar November 1998 The following example makes use of the Quoted-Printable encoding in order to represent non-ASCII characters. LOCATION;LANGUAGE=da:K=F8benhavn LOCATION;LANGUAGE=en:Copenhagen 4.2.11 Group or List Membership Parameter Name: MEMBER Purpose: To specify the group or list membership of the calendar user specified by the property. Format Definition: The property parameter is defined by the following notation: memberparam = "MEMBER" "=" DQUOTE cal-address DQUOTE *("," DQUOTE cal-address DQUOTE) Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter identifies the groups or list membership for the calendar user specified by the property. The parameter value either a single calendar address in a quoted-string or a COMMA character (US-ASCII decimal 44) list of calendar addresses, each in a quoted-string. The individual calendar address parameter values MUST each be specified in a quoted-string. Example: ATTENDEE;MEMBER="MAILTO:ietf-calsch@imc.org":MAILTO:jsmith@host.com ATTENDEE;MEMBER="MAILTO:projectA@host.com","MAILTO:projectB@host. com":MAILTO:janedoe@host.com 4.2.12 Participation Status Parameter Name: PARTSTAT Purpose: To specify the participation status for the calendar user specified by the property. Format Definition: The property parameter is defined by the following notation: partstatparam = "PARTSTAT" "=" ("NEEDS-ACTION" ; Event needs action / "ACCEPTED" ; Event accepted / "DECLINED" ; Event declined Dawson & Stenerson Standards Track [Page 25] RFC 2445 iCalendar November 1998 / "TENTATIVE" ; Event tentatively ; accepted / "DELEGATED" ; Event delegated / x-name ; Experimental status / iana-token) ; Other IANA registered ; status ; These are the participation statuses for a "VEVENT". Default is ; NEEDS-ACTION partstatparam /= "PARTSTAT" "=" ("NEEDS-ACTION" ; To-do needs action / "ACCEPTED" ; To-do accepted / "DECLINED" ; To-do declined / "TENTATIVE" ; To-do tentatively ; accepted / "DELEGATED" ; To-do delegated / "COMPLETED" ; To-do completed. ; COMPLETED property has ;date/time completed. / "IN-PROCESS" ; To-do in process of ; being completed / x-name ; Experimental status / iana-token) ; Other IANA registered ; status ; These are the participation statuses for a "VTODO". Default is ; NEEDS-ACTION partstatparam /= "PARTSTAT" "=" ("NEEDS-ACTION" ; Journal needs action / "ACCEPTED" ; Journal accepted / "DECLINED" ; Journal declined / x-name ; Experimental status / iana-token) ; Other IANA registered ; status ; These are the participation statuses for a "VJOURNAL". Default is ; NEEDS-ACTION Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter identifies the participation status for the calendar user specified by the property value. The parameter values differ depending on whether they are associated with a group scheduled "VEVENT", "VTODO" or "VJOURNAL". The values MUST match one of the values allowed for the given calendar component. If not specified on a property that allows this parameter, the default value is NEEDS-ACTION. Example: ATTENDEE;PARTSTAT=DECLINED:MAILTO:jsmith@host.com Dawson & Stenerson Standards Track [Page 26] RFC 2445 iCalendar November 1998 4.2.13 Recurrence Identifier Range Parameter Name: RANGE Purpose: To specify the effective range of recurrence instances from the instance specified by the recurrence identifier specified by the property. Format Definition: The property parameter is defined by the following notation: rangeparam = "RANGE" "=" ("THISANDPRIOR" ; To specify all instances prior to the recurrence identifier / "THISANDFUTURE") ; To specify the instance specified by the recurrence identifier ; and all subsequent recurrence instances Description: The parameter can be specified on a property that specifies a recurrence identifier. The parameter specifies the effective range of recurrence instances that is specified by the property. The effective range is from the recurrence identified specified by the property. If this parameter is not specified an allowed property, then the default range is the single instance specified by the recurrence identifier value of the property. The parameter value can be "THISANDPRIOR" to indicate a range defined by the recurrence identified value of the property and all prior instances. The parameter value can also be "THISANDFUTURE" to indicate a range defined by the recurrence identifier and all subsequent instances. Example: RECURRENCE-ID;RANGE=THISANDPRIOR:19980401T133000Z 4.2.14 Alarm Trigger Relationship Parameter Name: RELATED Purpose: To specify the relationship of the alarm trigger with respect to the start or end of the calendar component. Format Definition: The property parameter is defined by the following notation: trigrelparam = "RELATED" "=" ("START" ; Trigger off of start / "END") ; Trigger off of end Dawson & Stenerson Standards Track [Page 27] RFC 2445 iCalendar November 1998 Description: The parameter can be specified on properties that specify an alarm trigger with a DURATION value type. The parameter specifies whether the alarm will trigger relative to the start or end of the calendar component. The parameter value START will set the alarm to trigger off the start of the calendar component; the parameter value END will set the alarm to trigger off the end of the calendar component. If the parameter is not specified on an allowable property, then the default is START. Example: TRIGGER;RELATED=END:PT5M 4.2.15 Relationship Type Parameter Name: RELTYPE Purpose: To specify the type of hierarchical relationship associated with the calendar component specified by the property. Format Definition: The property parameter is defined by the following notation: reltypeparam = "RELTYPE" "=" ("PARENT" ; Parent relationship. Default. / "CHILD" ; Child relationship / "SIBLING ; Sibling relationship / iana-token ; Some other IANA registered ; iCalendar relationship type / x-name) ; A non-standard, experimental ; relationship type Description: This parameter can be specified on a property that references another related calendar. The parameter specifies the hierarchical relationship type of the calendar component referenced by the property. The parameter value can be PARENT, to indicate that the referenced calendar component is a superior of calendar component; CHILD to indicate that the referenced calendar component is a subordinate of the calendar component; SIBLING to indicate that the referenced calendar component is a peer of the calendar component. If this parameter is not specified on an allowable property, the default relationship type is PARENT. Example: RELATED-TO;RELTYPE=SIBLING:<19960401-080045-4000F192713@host.com> Dawson & Stenerson Standards Track [Page 28] RFC 2445 iCalendar November 1998 4.2.16 Participation Role Parameter Name: ROLE Purpose: To specify the participation role for the calendar user specified by the property. Format Definition: The property parameter is defined by the following notation: roleparam = "ROLE" "=" ("CHAIR" ; Indicates chair of the ; calendar entity / "REQ-PARTICIPANT" ; Indicates a participant whose ; participation is required / "OPT-PARTICIPANT" ; Indicates a participant whose ; participation is optional / "NON-PARTICIPANT" ; Indicates a participant who is ; copied for information ; purposes only / x-name ; Experimental role / iana-token) ; Other IANA role ; Default is REQ-PARTICIPANT Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter specifies the participation role for the calendar user specified by the property in the group schedule calendar component. If not specified on a property that allows this parameter, the default value is REQ-PARTICIPANT. Example: ATTENDEE;ROLE=CHAIR:MAILTO:mrbig@host.com 4.2.17 RSVP Expectation Parameter Name: RSVP Purpose: To specify whether there is an expectation of a favor of a reply from the calendar user specified by the property value. Format Definition: The property parameter is defined by the following notation: rsvpparam = "RSVP" "=" ("TRUE" / "FALSE") ; Default is FALSE Dawson & Stenerson Standards Track [Page 29] RFC 2445 iCalendar November 1998 Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter identifies the expectation of a reply from the calendar user specified by the property value. This parameter is used by the "Organizer" to request a participation status reply from an "Attendee" of a group scheduled event or to-do. If not specified on a property that allows this parameter, the default value is FALSE. Example: ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host.com 4.2.18 Sent By Parameter Name: SENT-BY Purpose: To specify the calendar user that is acting on behalf of the calendar user specified by the property. Format Definition: The property parameter is defined by the following notation: sentbyparam = "SENT-BY" "=" DQUOTE cal-address DQUOTE Description: This parameter can be specified on properties with a CAL-ADDRESS value type. The parameter specifies the calendar user that is acting on behalf of the calendar user specified by the property. The parameter value MUST be a MAILTO URI as defined in [RFC 1738]. The individual calendar address parameter values MUST each be specified in a quoted-string. Example: ORGANIZER;SENT-BY="MAILTO:sray@host.com":MAILTO:jsmith@host.com 4.2.19 Time Zone Identifier Parameter Name: TZID Purpose: To specify the identifier for the time zone definition for a time component in the property value. Format Definition: This property parameter is defined by the following notation: tzidparam = "TZID" "=" [tzidprefix] paramtext CRLF tzidprefix = "/" Dawson & Stenerson Standards Track [Page 30] RFC 2445 iCalendar November 1998 Description: The parameter MUST be specified on the "DTSTART", "DTEND", "DUE", "EXDATE" and "RDATE" properties when either a DATE- TIME or TIME value type is specified and when the value is not either a UTC or a "floating" time. Refer to the DATE-TIME or TIME value type definition for a description of UTC and "floating time" formats. This property parameter specifies a text value which uniquely identifies the "VTIMEZONE" calendar component to be used when evaluating the time portion of the property. The value of the TZID property parameter will be equal to the value of the TZID property for the matching time zone definition. An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object. The parameter MUST be specified on properties with a DATE-TIME value if the DATE-TIME is not either a UTC or a "floating" time. The presence of the SOLIDUS character (US-ASCII decimal 47) as a prefix, indicates that this TZID represents a unique ID in a globally defined time zone registry (when such registry is defined). Note: This document does not define a naming convention for time zone identifiers. Implementers may want to use the naming conventions defined in existing time zone specifications such as the public-domain Olson database [TZ]. The specification of globally unique time zone identifiers is not addressed by this document and is left for future study. The following are examples of this property parameter: DTSTART;TZID=US-Eastern:19980119T020000 DTEND;TZID=US-Eastern:19980119T030000 The TZID property parameter MUST NOT be applied to DATE-TIME or TIME properties whose time values are specified in UTC. The use of local time in a DATE-TIME or TIME value without the TZID property parameter is to be interpreted as a local time value, regardless of the existence of "VTIMEZONE" calendar components in the iCalendar object. For more information see the sections on the data types DATE-TIME and TIME. Dawson & Stenerson Standards Track [Page 31] RFC 2445 iCalendar November 1998 4.2.20 Value Data Types Parameter Name: VALUE Purpose: To explicitly specify the data type format for a property value. Format Definition: The "VALUE" property parameter is defined by the following notation: valuetypeparam = "VALUE" "=" valuetype valuetype = ("BINARY" / "BOOLEAN" / "CAL-ADDRESS" / "DATE" / "DATE-TIME" / "DURATION" / "FLOAT" / "INTEGER" / "PERIOD" / "RECUR" / "TEXT" / "TIME" / "URI" / "UTC-OFFSET" / x-name ; Some experimental iCalendar data type. / iana-token) ; Some other IANA registered iCalendar data type. Description: The parameter specifies the data type and format of the property value. The property values MUST be of a single value type. For example, a "RDATE" property cannot have a combination of DATE- TIME and TIME value types. If the property's value is the default value type, then this parameter need not be specified. However, if the property's default value type is overridden by some other allowable value type, then this parameter MUST be specified. 4.3 Property Value Data Types The properties in an iCalendar object are strongly typed. The definition of each property restricts the value to be one of the value data types, or simply value types, defined in this section. The value type for a property will either be specified implicitly as the default value type or will be explicitly specified with the "VALUE" Dawson & Stenerson Standards Track [Page 32] RFC 2445 iCalendar November 1998 parameter. If the value type of a property is one of the alternate valid types, then it MUST be explicitly specified with the "VALUE" parameter. 4.3.1 Binary Value Name: BINARY Purpose: This value type is used to identify properties that contain a character encoding of inline binary data. For example, an inline attachment of an object code might be included in an iCalendar object. Formal Definition: The value type is defined by the following notation: binary = *(4b-char) [b-end] ; A "BASE64" encoded character string, as defined by [RFC 2045]. b-end = (2b-char "==") / (3b-char "=") b-char = ALPHA / DIGIT / "+" / "/" Description: Property values with this value type MUST also include the inline encoding parameter sequence of ";ENCODING=BASE64". That is, all inline binary data MUST first be character encoded using the "BASE64" encoding method defined in [RFC 2045]. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. Example: The following is an abridged example of a "BASE64" encoded binary value data. ATTACH;VALUE=BINARY;ENCODING=BASE64:MIICajCCAdOgAwIBAgICBEUwDQY JKoZIhvcNAQEEBQAwdzELMAkGA1UEBhMCVVMxLDAqBgNVBAoTI05ldHNjYXBlI ENvbW11bmljYXRpb25zIENvcnBvcmF0aW9uMRwwGgYDVQQLExNJbmZv <...remainder of "BASE64" encoded binary data...> 4.3.2 Boolean Value Name: BOOLEAN Purpose: This value type is used to identify properties that contain either a "TRUE" or "FALSE" Boolean value. Formal Definition: The value type is defined by the following notation: Dawson & Stenerson Standards Track [Page 33] RFC 2445 iCalendar November 1998 boolean = "TRUE" / "FALSE" Description: These values are case insensitive text. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. Example: The following is an example of a hypothetical property that has a BOOLEAN value type: GIBBERISH:TRUE 4.3.3 Calendar User Address Value Name: CAL-ADDRESS Purpose: This value type is used to identify properties that contain a calendar user address. Formal Definition: The value type is as defined by the following notation: cal-address = uri Description: The value is a URI as defined by [RFC 1738] or any other IANA registered form for a URI. When used to address an Internet email transport address for a calendar user, the value MUST be a MAILTO URI, as defined by [RFC 1738]. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. Example: ATTENDEE:MAILTO:jane_doe@host.com 4.3.4 Date Value Name: DATE Purpose: This value type is used to identify values that contain a calendar date. Formal Definition: The value type is defined by the following notation: date = date-value date-value = date-fullyear date-month date-mday date-fullyear = 4DIGIT Dawson & Stenerson Standards Track [Page 34] RFC 2445 iCalendar November 1998 date-month = 2DIGIT ;01-12 date-mday = 2DIGIT ;01-28, 01-29, 01-30, 01-31 ;based on month/year Description: If the property permits, multiple "date" values are specified as a COMMA character (US-ASCII decimal 44) separated list of values. The format for the value type is expressed as the [ISO 8601] complete representation, basic format for a calendar date. The textual format specifies a four-digit year, two-digit month, and two-digit day of the month. There are no separator characters between the year, month and day component text. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. Example: The following represents July 14, 1997: 19970714 4.3.5 Date-Time Value Name: DATE-TIME Purpose: This value type is used to identify values that specify a precise calendar date and time of day. Formal Definition: The value type is defined by the following notation: date-time = date "T" time ;As specified in the date and time ;value definitions Description: If the property permits, multiple "date-time" values are specified as a COMMA character (US-ASCII decimal 44) separated list of values. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. The "DATE-TIME" data type is used to identify values that contain a precise calendar date and time of day. The format is based on the [ISO 8601] complete representation, basic format for a calendar date and time of day. The text format is a concatenation of the "date", followed by the LATIN CAPITAL LETTER T character (US-ASCII decimal 84) time designator, followed by the "time" format. The "DATE-TIME" data type expresses time values in three forms: The form of date and time with UTC offset MUST NOT be used. For example, the following is not valid for a date-time value: Dawson & Stenerson Standards Track [Page 35] RFC 2445 iCalendar November 1998 DTSTART:19980119T230000-0800 ;Invalid time format FORM #1: DATE WITH LOCAL TIME The date with local time form is simply a date-time value that does not contain the UTC designator nor does it reference a time zone. For example, the following represents Janurary 18, 1998, at 11 PM: DTSTART:19980118T230000 Date-time values of this type are said to be "floating" and are not bound to any time zone in particular. They are used to represent the same hour, minute, and second value regardless of which time zone is currently being observed. For example, an event can be defined that indicates that an individual will be busy from 11:00 AM to 1:00 PM every day, no matter which time zone the person is in. In these cases, a local time can be specified. The recipient of an iCalendar object with a property value consisting of a local time, without any relative time zone information, SHOULD interpret the value as being fixed to whatever time zone the ATTENDEE is in at any given moment. This means that two ATTENDEEs, in different time zones, receiving the same event definition as a floating time, may be participating in the event at different actual times. Floating time SHOULD only be used where that is the reasonable behavior. In most cases, a fixed time is desired. To properly communicate a fixed time in a property value, either UTC time or local time with time zone reference MUST be specified. The use of local time in a DATE-TIME value without the TZID property parameter is to be interpreted as floating time, regardless of the existence of "VTIMEZONE" calendar components in the iCalendar object. FORM #2: DATE WITH UTC TIME The date with UTC time, or absolute time, is identified by a LATIN CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC designator, appended to the time value. For example, the following represents January 19, 1998, at 0700 UTC: DTSTART:19980119T070000Z The TZID property parameter MUST NOT be applied to DATE-TIME properties whose time values are specified in UTC. FORM #3: DATE WITH LOCAL TIME AND TIME ZONE REFERENCE Dawson & Stenerson Standards Track [Page 36] RFC 2445 iCalendar November 1998 The date and local time with reference to time zone information is identified by the use the TZID property parameter to reference the appropriate time zone definition. TZID is discussed in detail in the section on Time Zone. For example, the following represents 2 AM in New York on Janurary 19, 1998: DTSTART;TZID=US-Eastern:19980119T020000 Example: The following represents July 14, 1997, at 1:30 PM in New York City in each of the three time formats, using the "DTSTART" property. DTSTART:19970714T133000 ;Local time DTSTART:19970714T173000Z ;UTC time DTSTART;TZID=US-Eastern:19970714T133000 ;Local time and time ; zone reference A time value MUST ONLY specify 60 seconds when specifying the periodic "leap second" in the time value. For example: COMPLETED:19970630T235960Z 4.3.6 Duration Value Name: DURATION Purpose: This value type is used to identify properties that contain a duration of time. Formal Definition: The value type is defined by the following notation: dur-value = (["+"] / "-") "P" (dur-date / dur-time / dur-week) dur-date = dur-day [dur-time] dur-time = "T" (dur-hour / dur-minute / dur-second) dur-week = 1*DIGIT "W" dur-hour = 1*DIGIT "H" [dur-minute] dur-minute = 1*DIGIT "M" [dur-second] dur-second = 1*DIGIT "S" dur-day = 1*DIGIT "D" Description: If the property permits, multiple "duration" values are specified by a COMMA character (US-ASCII decimal 44) separated list of values. The format is expressed as the [ISO 8601] basic format for the duration of time. The format can represent durations in terms of weeks, days, hours, minutes, and seconds. Dawson & Stenerson Standards Track [Page 37] RFC 2445 iCalendar November 1998 No additional content value encoding (i.e., BACKSLASH character encoding) are defined for this value type. Example: A duration of 15 days, 5 hours and 20 seconds would be: P15DT5H0M20S A duration of 7 weeks would be: P7W 4.3.7 Float Value Name: FLOAT Purpose: This value type is used to identify properties that contain a real number value. Formal Definition: The value type is defined by the following notation: float = (["+"] / "-") 1*DIGIT ["." 1*DIGIT] Description: If the property permits, multiple "float" values are specified by a COMMA character (US-ASCII decimal 44) separated list of values. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. Example: 1000000.0000001 1.333 -3.14 4.3.8 Integer Value Name:INTEGER Purpose: This value type is used to identify properties that contain a signed integer value. Formal Definition: The value type is defined by the following notation: integer = (["+"] / "-") 1*DIGIT Dawson & Stenerson Standards Track [Page 38] RFC 2445 iCalendar November 1998 Description: If the property permits, multiple "integer" values are specified by a COMMA character (US-ASCII decimal 44) separated list of values. The valid range for "integer" is -2147483648 to 2147483647. If the sign is not specified, then the value is assumed to be positive. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. Example: 1234567890 -1234567890 +1234567890 432109876 4.3.9 Period of Time Value Name: PERIOD Purpose: This value type is used to identify values that contain a precise period of time. Formal Definition: The data type is defined by the following notation: period = period-explicit / period-start period-explicit = date-time "/" date-time ; [ISO 8601] complete representation basic format for a period of ; time consisting of a start and end. The start MUST be before the ; end. period-start = date-time "/" dur-value ; [ISO 8601] complete representation basic format for a period of ; time consisting of a start and positive duration of time. Description: If the property permits, multiple "period" values are specified by a COMMA character (US-ASCII decimal 44) separated list of values. There are two forms of a period of time. First, a period of time is identified by its start and its end. This format is expressed as the [ISO 8601] complete representation, basic format for "DATE-TIME" start of the period, followed by a SOLIDUS character (US-ASCII decimal 47), followed by the "DATE-TIME" of the end of the period. The start of the period MUST be before the end of the period. Second, a period of time can also be defined by a start and a positive duration of time. The format is expressed as the [ISO 8601] complete representation, basic format for the "DATE-TIME" start of Dawson & Stenerson Standards Track [Page 39] RFC 2445 iCalendar November 1998 the period, followed by a SOLIDUS character (US-ASCII decimal 47), followed by the [ISO 8601] basic format for "DURATION" of the period. Example: The period starting at 18:00:00 UTC, on January 1, 1997 and ending at 07:00:00 UTC on January 2, 1997 would be: 19970101T180000Z/19970102T070000Z The period start at 18:00:00 on January 1, 1997 and lasting 5 hours and 30 minutes would be: 19970101T180000Z/PT5H30M No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. 4.3.10 Recurrence Rule Value Name: RECUR Purpose: This value type is used to identify properties that contain a recurrence rule specification. Formal Definition: The value type is defined by the following notation: recur = "FREQ"=freq *( ; either UNTIL or COUNT may appear in a 'recur', ; but UNTIL and COUNT MUST NOT occur in the same 'recur' ( ";" "UNTIL" "=" enddate ) / ( ";" "COUNT" "=" 1*DIGIT ) / ; the rest of these keywords are optional, ; but MUST NOT occur more than once ( ";" "INTERVAL" "=" 1*DIGIT ) / ( ";" "BYSECOND" "=" byseclist ) / ( ";" "BYMINUTE" "=" byminlist ) / ( ";" "BYHOUR" "=" byhrlist ) / ( ";" "BYDAY" "=" bywdaylist ) / ( ";" "BYMONTHDAY" "=" bymodaylist ) / ( ";" "BYYEARDAY" "=" byyrdaylist ) / ( ";" "BYWEEKNO" "=" bywknolist ) / ( ";" "BYMONTH" "=" bymolist ) / ( ";" "BYSETPOS" "=" bysplist ) / ( ";" "WKST" "=" weekday ) / Dawson & Stenerson Standards Track [Page 40] RFC 2445 iCalendar November 1998 ( ";" x-name "=" text ) ) freq = "SECONDLY" / "MINUTELY" / "HOURLY" / "DAILY" / "WEEKLY" / "MONTHLY" / "YEARLY" enddate = date enddate =/ date-time ;An UTC value byseclist = seconds / ( seconds *("," seconds) ) seconds = 1DIGIT / 2DIGIT ;0 to 59 byminlist = minutes / ( minutes *("," minutes) ) minutes = 1DIGIT / 2DIGIT ;0 to 59 byhrlist = hour / ( hour *("," hour) ) hour = 1DIGIT / 2DIGIT ;0 to 23 bywdaylist = weekdaynum / ( weekdaynum *("," weekdaynum) ) weekdaynum = [([plus] ordwk / minus ordwk)] weekday plus = "+" minus = "-" ordwk = 1DIGIT / 2DIGIT ;1 to 53 weekday = "SU" / "MO" / "TU" / "WE" / "TH" / "FR" / "SA" ;Corresponding to SUNDAY, MONDAY, TUESDAY, WEDNESDAY, THURSDAY, ;FRIDAY, SATURDAY and SUNDAY days of the week. bymodaylist = monthdaynum / ( monthdaynum *("," monthdaynum) ) monthdaynum = ([plus] ordmoday) / (minus ordmoday) ordmoday = 1DIGIT / 2DIGIT ;1 to 31 byyrdaylist = yeardaynum / ( yeardaynum *("," yeardaynum) ) yeardaynum = ([plus] ordyrday) / (minus ordyrday) ordyrday = 1DIGIT / 2DIGIT / 3DIGIT ;1 to 366 bywknolist = weeknum / ( weeknum *("," weeknum) ) Dawson & Stenerson Standards Track [Page 41] RFC 2445 iCalendar November 1998 weeknum = ([plus] ordwk) / (minus ordwk) bymolist = monthnum / ( monthnum *("," monthnum) ) monthnum = 1DIGIT / 2DIGIT ;1 to 12 bysplist = setposday / ( setposday *("," setposday) ) setposday = yeardaynum Description: If the property permits, multiple "recur" values are specified by a COMMA character (US-ASCII decimal 44) separated list of values. The value type is a structured value consisting of a list of one or more recurrence grammar parts. Each rule part is defined by a NAME=VALUE pair. The rule parts are separated from each other by the SEMICOLON character (US-ASCII decimal 59). The rule parts are not ordered in any particular sequence. Individual rule parts MUST only be specified once. The FREQ rule part identifies the type of recurrence rule. This rule part MUST be specified in the recurrence rule. Valid values include SECONDLY, to specify repeating events based on an interval of a second or more; MINUTELY, to specify repeating events based on an interval of a minute or more; HOURLY, to specify repeating events based on an interval of an hour or more; DAILY, to specify repeating events based on an interval of a day or more; WEEKLY, to specify repeating events based on an interval of a week or more; MONTHLY, to specify repeating events based on an interval of a month or more; and YEARLY, to specify repeating events based on an interval of a year or more. The INTERVAL rule part contains a positive integer representing how often the recurrence rule repeats. The default value is "1", meaning every second for a SECONDLY rule, or every minute for a MINUTELY rule, every hour for an HOURLY rule, every day for a DAILY rule, every week for a WEEKLY rule, every month for a MONTHLY rule and every year for a YEARLY rule. The UNTIL rule part defines a date-time value which bounds the recurrence rule in an inclusive manner. If the value specified by UNTIL is synchronized with the specified recurrence, this date or date-time becomes the last instance of the recurrence. If specified as a date-time value, then it MUST be specified in an UTC time format. If not present, and the COUNT rule part is also not present, the RRULE is considered to repeat forever. The COUNT rule part defines the number of occurrences at which to range-bound the recurrence. The "DTSTART" property value, if Dawson & Stenerson Standards Track [Page 42] RFC 2445 iCalendar November 1998 specified, counts as the first occurrence. The BYSECOND rule part specifies a COMMA character (US-ASCII decimal 44) separated list of seconds within a minute. Valid values are 0 to 59. The BYMINUTE rule part specifies a COMMA character (US-ASCII decimal 44) separated list of minutes within an hour. Valid values are 0 to 59. The BYHOUR rule part specifies a COMMA character (US- ASCII decimal 44) separated list of hours of the day. Valid values are 0 to 23. The BYDAY rule part specifies a COMMA character (US-ASCII decimal 44) separated list of days of the week; MO indicates Monday; TU indicates Tuesday; WE indicates Wednesday; TH indicates Thursday; FR indicates Friday; SA indicates Saturday; SU indicates Sunday. Each BYDAY value can also be preceded by a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific day within the MONTHLY or YEARLY RRULE. For example, within a MONTHLY rule, +1MO (or simply 1MO) represents the first Monday within the month, whereas -1MO represents the last Monday of the month. If an integer modifier is not present, it means all days of this type within the specified frequency. For example, within a MONTHLY rule, MO represents all Mondays within the month. The BYMONTHDAY rule part specifies a COMMA character (ASCII decimal 44) separated list of days of the month. Valid values are 1 to 31 or -31 to -1. For example, -10 represents the tenth to the last day of the month. The BYYEARDAY rule part specifies a COMMA character (US-ASCII decimal 44) separated list of days of the year. Valid values are 1 to 366 or -366 to -1. For example, -1 represents the last day of the year (December 31st) and -306 represents the 306th to the last day of the year (March 1st). The BYWEEKNO rule part specifies a COMMA character (US-ASCII decimal 44) separated list of ordinals specifying weeks of the year. Valid values are 1 to 53 or -53 to -1. This corresponds to weeks according to week numbering as defined in [ISO 8601]. A week is defined as a seven day period, starting on the day of the week defined to be the week start (see WKST). Week number one of the calendar year is the first week which contains at least four (4) days in that calendar year. This rule part is only valid for YEARLY rules. For example, 3 represents the third week of the year. Note: Assuming a Monday week start, week 53 can only occur when Thursday is January 1 or if it is a leap year and Wednesday is January 1. Dawson & Stenerson Standards Track [Page 43] RFC 2445 iCalendar November 1998 The BYMONTH rule part specifies a COMMA character (US-ASCII decimal 44) separated list of months of the year. Valid values are 1 to 12. The WKST rule part specifies the day on which the workweek starts. Valid values are MO, TU, WE, TH, FR, SA and SU. This is significant when a WEEKLY RRULE has an interval greater than 1, and a BYDAY rule part is specified. This is also significant when in a YEARLY RRULE when a BYWEEKNO rule part is specified. The default value is MO. The BYSETPOS rule part specifies a COMMA character (US-ASCII decimal 44) separated list of values which corresponds to the nth occurrence within the set of events specified by the rule. Valid values are 1 to 366 or -366 to -1. It MUST only be used in conjunction with another BYxxx rule part. For example "the last work day of the month" could be represented as: RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-1 Each BYSETPOS value can include a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific occurrence within the set of events specified by the rule. If BYxxx rule part values are found which are beyond the available scope (ie, BYMONTHDAY=30 in February), they are simply ignored. Information, not contained in the rule, necessary to determine the various recurrence instance start time and dates are derived from the Start Time (DTSTART) entry attribute. For example, "FREQ=YEARLY;BYMONTH=1" doesn't specify a specific day within the month or a time. This information would be the same as what is specified for DTSTART. BYxxx rule parts modify the recurrence in some manner. BYxxx rule parts for a period of time which is the same or greater than the frequency generally reduce or limit the number of occurrences of the recurrence generated. For example, "FREQ=DAILY;BYMONTH=1" reduces the number of recurrence instances from all days (if BYMONTH tag is not present) to all days in January. BYxxx rule parts for a period of time less than the frequency generally increase or expand the number of occurrences of the recurrence. For example, "FREQ=YEARLY;BYMONTH=1,2" increases the number of days within the yearly recurrence set from 1 (if BYMONTH tag is not present) to 2. If multiple BYxxx rule parts are specified, then after evaluating the specified FREQ and INTERVAL rule parts, the BYxxx rule parts are applied to the current set of evaluated occurrences in the following order: BYMONTH, BYWEEKNO, BYYEARDAY, BYMONTHDAY, BYDAY, BYHOUR, BYMINUTE, BYSECOND and BYSETPOS; then COUNT and UNTIL are evaluated. Dawson & Stenerson Standards Track [Page 44] RFC 2445 iCalendar November 1998 Here is an example of evaluating multiple BYxxx rule parts. DTSTART;TZID=US-Eastern:19970105T083000 RRULE:FREQ=YEARLY;INTERVAL=2;BYMONTH=1;BYDAY=SU;BYHOUR=8,9; BYMINUTE=30 First, the "INTERVAL=2" would be applied to "FREQ=YEARLY" to arrive at "every other year". Then, "BYMONTH=1" would be applied to arrive at "every January, every other year". Then, "BYDAY=SU" would be applied to arrive at "every Sunday in January, every other year". Then, "BYHOUR=8,9" would be applied to arrive at "every Sunday in January at 8 AM and 9 AM, every other year". Then, "BYMINUTE=30" would be applied to arrive at "every Sunday in January at 8:30 AM and 9:30 AM, every other year". Then, lacking information from RRULE, the second is derived from DTSTART, to end up in "every Sunday in January at 8:30:00 AM and 9:30:00 AM, every other year". Similarly, if the BYMINUTE, BYHOUR, BYDAY, BYMONTHDAY or BYMONTH rule part were missing, the appropriate minute, hour, day or month would have been retrieved from the "DTSTART" property. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. Example: The following is a rule which specifies 10 meetings which occur every other day: FREQ=DAILY;COUNT=10;INTERVAL=2 There are other examples specified in the "RRULE" specification. 4.3.11 Text Value Name: TEXT Purpose This value type is used to identify values that contain human readable text. Formal Definition: The character sets supported by this revision of iCalendar are UTF-8 and US ASCII thereof. The applicability to other character sets is for future work. The value type is defined by the following notation. text = *(TSAFE-CHAR / ":" / DQUOTE / ESCAPED-CHAR) ; Folded according to description above ESCAPED-CHAR = "\\" / "\;" / "\," / "\N" / "\n") ; \\ encodes \, \N or \n encodes newline ; \; encodes ;, \, encodes , Dawson & Stenerson Standards Track [Page 45] RFC 2445 iCalendar November 1998 TSAFE-CHAR = %x20-21 / %x23-2B / %x2D-39 / %x3C-5B %x5D-7E / NON-US-ASCII ; Any character except CTLs not needed by the current ; character set, DQUOTE, ";", ":", "\", "," Note: Certain other character sets may require modification of the above definitions, but this is beyond the scope of this document. Description: If the property permits, multiple "text" values are specified by a COMMA character (US-ASCII decimal 44) separated list of values. The language in which the text is represented can be controlled by the "LANGUAGE" property parameter. An intentional formatted text line break MUST only be included in a "TEXT" property value by representing the line break with the character sequence of BACKSLASH (US-ASCII decimal 92), followed by a LATIN SMALL LETTER N (US-ASCII decimal 110) or a LATIN CAPITAL LETTER N (US-ASCII decimal 78), that is "\n" or "\N". The "TEXT" property values may also contain special characters that are used to signify delimiters, such as a COMMA character for lists of values or a SEMICOLON character for structured values. In order to support the inclusion of these special characters in "TEXT" property values, they MUST be escaped with a BACKSLASH character. A BACKSLASH character (US-ASCII decimal 92) in a "TEXT" property value MUST be escaped with another BACKSLASH character. A COMMA character in a "TEXT" property value MUST be escaped with a BACKSLASH character (US-ASCII decimal 92). A SEMICOLON character in a "TEXT" property value MUST be escaped with a BACKSLASH character (US-ASCII decimal 92). However, a COLON character in a "TEXT" property value SHALL NOT be escaped with a BACKSLASH character.Example: A multiple line value of: Project XYZ Final Review Conference Room - 3B Come Prepared. would be represented as: Project XYZ Final Review\nConference Room - 3B\nCome Prepared. Dawson & Stenerson Standards Track [Page 46] RFC 2445 iCalendar November 1998 4.3.12 Time Value Name: TIME Purpose: This value type is used to identify values that contain a time of day. Formal Definition: The data type is defined by the following notation: time = time-hour time-minute time-second [time-utc] time-hour = 2DIGIT ;00-23 time-minute = 2DIGIT ;00-59 time-second = 2DIGIT ;00-60 ;The "60" value is used to account for "leap" seconds. time-utc = "Z" Description: If the property permits, multiple "time" values are specified by a COMMA character (US-ASCII decimal 44) separated list of values. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. The "TIME" data type is used to identify values that contain a time of day. The format is based on the [ISO 8601] complete representation, basic format for a time of day. The text format consists of a two-digit 24-hour of the day (i.e., values 0-23), two- digit minute in the hour (i.e., values 0-59), and two-digit seconds in the minute (i.e., values 0-60). The seconds value of 60 MUST only to be used to account for "leap" seconds. Fractions of a second are not supported by this format. In parallel to the "DATE-TIME" definition above, the "TIME" data type expresses time values in three forms: The form of time with UTC offset MUST NOT be used. For example, the following is NOT VALID for a time value: 230000-0800 ;Invalid time format FORM #1 LOCAL TIME The local time form is simply a time value that does not contain the UTC designator nor does it reference a time zone. For example, 11:00 PM: 230000 Dawson & Stenerson Standards Track [Page 47] RFC 2445 iCalendar November 1998 Time values of this type are said to be "floating" and are not bound to any time zone in particular. They are used to represent the same hour, minute, and second value regardless of which time zone is currently being observed. For example, an event can be defined that indicates that an individual will be busy from 11:00 AM to 1:00 PM every day, no matter which time zone the person is in. In these cases, a local time can be specified. The recipient of an iCalendar object with a property value consisting of a local time, without any relative time zone information, SHOULD interpret the value as being fixed to whatever time zone the ATTENDEE is in at any given moment. This means that two ATTENDEEs may participate in the same event at different UTC times; floating time SHOULD only be used where that is reasonable behavior. In most cases, a fixed time is desired. To properly communicate a fixed time in a property value, either UTC time or local time with time zone reference MUST be specified. The use of local time in a TIME value without the TZID property parameter is to be interpreted as a local time value, regardless of the existence of "VTIMEZONE" calendar components in the iCalendar object. FORM #2: UTC TIME UTC time, or absolute time, is identified by a LATIN CAPITAL LETTER Z suffix character (US-ASCII decimal 90), the UTC designator, appended to the time value. For example, the following represents 07:00 AM UTC: 070000Z The TZID property parameter MUST NOT be applied to TIME properties whose time values are specified in UTC. FORM #3: LOCAL TIME AND TIME ZONE REFERENCE The local time with reference to time zone information form is identified by the use the TZID property parameter to reference the appropriate time zone definition. TZID is discussed in detail in the section on Time Zone. Example: The following represents 8:30 AM in New York in Winter, five hours behind UTC, in each of the three formats using the "X- TIMEOFDAY" non-standard property: Dawson & Stenerson Standards Track [Page 48] RFC 2445 iCalendar November 1998 X-TIMEOFDAY:083000 X-TIMEOFDAY:133000Z X-TIMEOFDAY;TZID=US-Eastern:083000 4.3.13 URI Value Name: URI Purpose: This value type is used to identify values that contain a uniform resource identifier (URI) type of reference to the property value. Formal Definition: The data type is defined by the following notation: uri = Description: This data type might be used to reference binary information, for values that are large, or otherwise undesirable to include directly in the iCalendar object. The URI value formats in RFC 1738, RFC 2111 and any other IETF registered value format can be specified. Any IANA registered URI format can be used. These include, but are not limited to, those defined in RFC 1738 and RFC 2111. When a property parameter value is a URI value type, the URI MUST be specified as a quoted-string value. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. Example: The following is a URI for a network file: http://host1.com/my-report.txt 4.3.14 UTC Offset Value Name: UTC-OFFSET Purpose: This value type is used to identify properties that contain an offset from UTC to local time. Formal Definition: The data type is defined by the following notation: Dawson & Stenerson Standards Track [Page 49] RFC 2445 iCalendar November 1998 utc-offset = time-numzone ;As defined above in time data type time-numzone = ("+" / "-") time-hour time-minute [time- second] Description: The PLUS SIGN character MUST be specified for positive UTC offsets (i.e., ahead of UTC). The value of "-0000" and "-000000" are not allowed. The time-second, if present, may not be 60; if absent, it defaults to zero. No additional content value encoding (i.e., BACKSLASH character encoding) is defined for this value type. Example: The following UTC offsets are given for standard time for New York (five hours behind UTC) and Geneva (one hour ahead of UTC): -0500 +0100 4.4 iCalendar Object The Calendaring and Scheduling Core Object is a collection of calendaring and scheduling information. Typically, this information will consist of a single iCalendar object. However, multiple iCalendar objects can be sequentially grouped together. The first line and last line of the iCalendar object MUST contain a pair of iCalendar object delimiter strings. The syntax for an iCalendar object is as follows: icalobject = 1*("BEGIN" ":" "VCALENDAR" CRLF icalbody "END" ":" "VCALENDAR" CRLF) The following is a simple example of an iCalendar object: BEGIN:VCALENDAR VERSION:2.0 PRODID:-//hacksw/handcal//NONSGML v1.0//EN BEGIN:VEVENT DTSTART:19970714T170000Z DTEND:19970715T035959Z SUMMARY:Bastille Day Party END:VEVENT END:VCALENDAR Dawson & Stenerson Standards Track [Page 50] RFC 2445 iCalendar November 1998 4.5 Property A property is the definition of an individual attribute describing a calendar or a calendar component. A property takes the form defined by the "contentline" notation defined in section 4.1.1. The following is an example of a property: DTSTART:19960415T133000Z This memo imposes no ordering of properties within an iCalendar object. Property names, parameter names and enumerated parameter values are case insensitive. For example, the property name "DUE" is the same as "due" and "Due", DTSTART;TZID=US-Eastern:19980714T120000 is the same as DtStart;TzID=US-Eastern:19980714T120000. 4.6 Calendar Components The body of the iCalendar object consists of a sequence of calendar properties and one or more calendar components. The calendar properties are attributes that apply to the calendar as a whole. The calendar components are collections of properties that express a particular calendar semantic. For example, the calendar component can specify an event, a to-do, a journal entry, time zone information, or free/busy time information, or an alarm. The body of the iCalendar object is defined by the following notation: icalbody = calprops component calprops = 2*( ; 'prodid' and 'version' are both REQUIRED, ; but MUST NOT occur more than once prodid /version / ; 'calscale' and 'method' are optional, ; but MUST NOT occur more than once calscale / method / x-prop Dawson & Stenerson Standards Track [Page 51] RFC 2445 iCalendar November 1998 ) component = 1*(eventc / todoc / journalc / freebusyc / / timezonec / iana-comp / x-comp) iana-comp = "BEGIN" ":" iana-token CRLF 1*contentline "END" ":" iana-token CRLF x-comp = "BEGIN" ":" x-name CRLF 1*contentline "END" ":" x-name CRLF An iCalendar object MUST include the "PRODID" and "VERSION" calendar properties. In addition, it MUST include at least one calendar component. Special forms of iCalendar objects are possible to publish just busy time (i.e., only a "VFREEBUSY" calendar component) or time zone (i.e., only a "VTIMEZONE" calendar component) information. In addition, a complex iCalendar object is possible that is used to capture a complete snapshot of the contents of a calendar (e.g., composite of many different calendar components). More commonly, an iCalendar object will consist of just a single "VEVENT", "VTODO" or "VJOURNAL" calendar component. 4.6.1 Event Component Component Name: "VEVENT" Purpose: Provide a grouping of component properties that describe an event. Format Definition: A "VEVENT" calendar component is defined by the following notation: eventc = "BEGIN" ":" "VEVENT" CRLF eventprop *alarmc "END" ":" "VEVENT" CRLF eventprop = *( ; the following are optional, ; but MUST NOT occur more than once class / created / description / dtstart / geo / Dawson & Stenerson Standards Track [Page 52] RFC 2445 iCalendar November 1998 last-mod / location / organizer / priority / dtstamp / seq / status / summary / transp / uid / url / recurid / ; either 'dtend' or 'duration' may appear in ; a 'eventprop', but 'dtend' and 'duration' ; MUST NOT occur in the same 'eventprop' dtend / duration / ; the following are optional, ; and MAY occur more than once attach / attendee / categories / comment / contact / exdate / exrule / rstatus / related / resources / rdate / rrule / x-prop ) Description: A "VEVENT" calendar component is a grouping of component properties, and possibly including "VALARM" calendar components, that represents a scheduled amount of time on a calendar. For example, it can be an activity; such as a one-hour long, department meeting from 8:00 AM to 9:00 AM, tomorrow. Generally, an event will take up time on an individual calendar. Hence, the event will appear as an opaque interval in a search for busy time. Alternately, the event can have its Time Transparency set to "TRANSPARENT" in order to prevent blocking of the event in searches for busy time. The "VEVENT" is also the calendar component used to specify an anniversary or daily reminder within a calendar. These events have a DATE value type for the "DTSTART" property instead of the default data type of DATE-TIME. If such a "VEVENT" has a "DTEND" property, it MUST be specified as a DATE value also. The anniversary type of "VEVENT" can span more than one date (i.e, "DTEND" property value is set to a calendar date after the "DTSTART" property value). The "DTSTART" property for a "VEVENT" specifies the inclusive start of the event. For recurring events, it also specifies the very first instance in the recurrence set. The "DTEND" property for a "VEVENT" calendar component specifies the non-inclusive end of the event. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE data type but no "DTEND" property, the events non-inclusive end is the end of the calendar date specified by the "DTSTART" property. For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE-TIME data type but no "DTEND" property, the event ends on the same calendar date and time of day specified by the "DTSTART" property. Dawson & Stenerson Standards Track [Page 53] RFC 2445 iCalendar November 1998 The "VEVENT" calendar component cannot be nested within another calendar component. However, "VEVENT" calendar components can be related to each other or to a "VTODO" or to a "VJOURNAL" calendar component with the "RELATED-TO" property. Example: The following is an example of the "VEVENT" calendar component used to represent a meeting that will also be opaque to searches for busy time: BEGIN:VEVENT UID:19970901T130000Z-123401@host.com DTSTAMP:19970901T1300Z DTSTART:19970903T163000Z DTEND:19970903T190000Z SUMMARY:Annual Employee Review CLASS:PRIVATE CATEGORIES:BUSINESS,HUMAN RESOURCES END:VEVENT The following is an example of the "VEVENT" calendar component used to represent a reminder that will not be opaque, but rather transparent, to searches for busy time: BEGIN:VEVENT UID:19970901T130000Z-123402@host.com DTSTAMP:19970901T1300Z DTSTART:19970401T163000Z DTEND:19970402T010000Z SUMMARY:Laurel is in sensitivity awareness class. CLASS:PUBLIC CATEGORIES:BUSINESS,HUMAN RESOURCES TRANSP:TRANSPARENT END:VEVENT The following is an example of the "VEVENT" calendar component used to represent an anniversary that will occur annually. Since it takes up no time, it will not appear as opaque in a search for busy time; no matter what the value of the "TRANSP" property indicates: BEGIN:VEVENT UID:19970901T130000Z-123403@host.com DTSTAMP:19970901T1300Z DTSTART:19971102 SUMMARY:Our Blissful Anniversary CLASS:CONFIDENTIAL CATEGORIES:ANNIVERSARY,PERSONAL,SPECIAL OCCASION RRULE:FREQ=YEARLY END:VEVENT Dawson & Stenerson Standards Track [Page 54] RFC 2445 iCalendar November 1998 4.6.2 To-do Component Component Name: VTODO Purpose: Provide a grouping of calendar properties that describe a to-do. Formal Definition: A "VTODO" calendar component is defined by the following notation: todoc = "BEGIN" ":" "VTODO" CRLF todoprop *alarmc "END" ":" "VTODO" CRLF todoprop = *( ; the following are optional, ; but MUST NOT occur more than once class / completed / created / description / dtstamp / dtstart / geo / last-mod / location / organizer / percent / priority / recurid / seq / status / summary / uid / url / ; either 'due' or 'duration' may appear in ; a 'todoprop', but 'due' and 'duration' ; MUST NOT occur in the same 'todoprop' due / duration / ; the following are optional, ; and MAY occur more than once attach / attendee / categories / comment / contact / exdate / exrule / rstatus / related / resources / rdate / rrule / x-prop ) Description: A "VTODO" calendar component is a grouping of component properties and possibly "VALARM" calendar components that represent an action-item or assignment. For example, it can be used to represent an item of work assigned to an individual; such as "turn in travel expense today". The "VTODO" calendar component cannot be nested within another calendar component. However, "VTODO" calendar components can be related to each other or to a "VTODO" or to a "VJOURNAL" calendar component with the "RELATED-TO" property. Dawson & Stenerson Standards Track [Page 55] RFC 2445 iCalendar November 1998 A "VTODO" calendar component without the "DTSTART" and "DUE" (or "DURATION") properties specifies a to-do that will be associated with each successive calendar date, until it is completed. Example: The following is an example of a "VTODO" calendar component: BEGIN:VTODO UID:19970901T130000Z-123404@host.com DTSTAMP:19970901T1300Z DTSTART:19970415T133000Z DUE:19970416T045959Z SUMMARY:1996 Income Tax Preparation CLASS:CONFIDENTIAL CATEGORIES:FAMILY,FINANCE PRIORITY:1 STATUS:NEEDS-ACTION END:VTODO 4.6.3 Journal Component Component Name: VJOURNAL Purpose: Provide a grouping of component properties that describe a journal entry. Formal Definition: A "VJOURNAL" calendar component is defined by the following notation: journalc = "BEGIN" ":" "VJOURNAL" CRLF jourprop "END" ":" "VJOURNAL" CRLF jourprop = *( ; the following are optional, ; but MUST NOT occur more than once class / created / description / dtstart / dtstamp / last-mod / organizer / recurid / seq / status / summary / uid / url / ; the following are optional, ; and MAY occur more than once attach / attendee / categories / comment / contact / exdate / exrule / related / rdate / rrule / rstatus / x-prop Dawson & Stenerson Standards Track [Page 56] RFC 2445 iCalendar November 1998 ) Description: A "VJOURNAL" calendar component is a grouping of component properties that represent one or more descriptive text notes associated with a particular calendar date. The "DTSTART" property is used to specify the calendar date that the journal entry is associated with. Generally, it will have a DATE value data type, but it can also be used to specify a DATE-TIME value data type. Examples of a journal entry include a daily record of a legislative body or a journal entry of individual telephone contacts for the day or an ordered list of accomplishments for the day. The "VJOURNAL" calendar component can also be used to associate a document with a calendar date. The "VJOURNAL" calendar component does not take up time on a calendar. Hence, it does not play a role in free or busy time searches - - it is as though it has a time transparency value of TRANSPARENT. It is transparent to any such searches. The "VJOURNAL" calendar component cannot be nested within another calendar component. However, "VJOURNAL" calendar components can be related to each other or to a "VEVENT" or to a "VTODO" calendar component, with the "RELATED-TO" property. Example: The following is an example of the "VJOURNAL" calendar component: BEGIN:VJOURNAL UID:19970901T130000Z-123405@host.com DTSTAMP:19970901T1300Z DTSTART;VALUE=DATE:19970317 SUMMARY:Staff meeting minutes DESCRIPTION:1. Staff meeting: Participants include Joe\, Lisa and Bob. Aurora project plans were reviewed. There is currently no budget reserves for this project. Lisa will escalate to management. Next meeting on Tuesday.\n 2. Telephone Conference: ABC Corp. sales representative called to discuss new printer. Promised to get us a demo by Friday.\n 3. Henry Miller (Handsoff Insurance): Car was totaled by tree. Is looking into a loaner car. 654-2323 (tel). END:VJOURNAL Dawson & Stenerson Standards Track [Page 57] RFC 2445 iCalendar November 1998 4.6.4 Free/Busy Component Component Name: VFREEBUSY Purpose: Provide a grouping of component properties that describe either a request for free/busy time, describe a response to a request for free/busy time or describe a published set of busy time. Formal Definition: A "VFREEBUSY" calendar component is defined by the following notation: freebusyc = "BEGIN" ":" "VFREEBUSY" CRLF fbprop "END" ":" "VFREEBUSY" CRLF fbprop = *( ; the following are optional, ; but MUST NOT occur more than once contact / dtstart / dtend / duration / dtstamp / organizer / uid / url / ; the following are optional, ; and MAY occur more than once attendee / comment / freebusy / rstatus / x-prop ) Description: A "VFREEBUSY" calendar component is a grouping of component properties that represents either a request for, a reply to a request for free or busy time information or a published set of busy time information. When used to request free/busy time information, the "ATTENDEE" property specifies the calendar users whose free/busy time is being requested; the "ORGANIZER" property specifies the calendar user who is requesting the free/busy time; the "DTSTART" and "DTEND" properties specify the window of time for which the free/busy time is being requested; the "UID" and "DTSTAMP" properties are specified to assist in proper sequencing of multiple free/busy time requests. When used to reply to a request for free/busy time, the "ATTENDEE" property specifies the calendar user responding to the free/busy time request; the "ORGANIZER" property specifies the calendar user that originally requested the free/busy time; the "FREEBUSY" property specifies the free/busy time information (if it exists); and the Dawson & Stenerson Standards Track [Page 58] RFC 2445 iCalendar November 1998 "UID" and "DTSTAMP" properties are specified to assist in proper sequencing of multiple free/busy time replies. When used to publish busy time, the "ORGANIZER" property specifies the calendar user associated with the published busy time; the "DTSTART" and "DTEND" properties specify an inclusive time window that surrounds the busy time information; the "FREEBUSY" property specifies the published busy time information; and the "DTSTAMP" property specifies the date/time that iCalendar object was created. The "VFREEBUSY" calendar component cannot be nested within another calendar component. Multiple "VFREEBUSY" calendar components can be specified within an iCalendar object. This permits the grouping of Free/Busy information into logical collections, such as monthly groups of busy time information. The "VFREEBUSY" calendar component is intended for use in iCalendar object methods involving requests for free time, requests for busy time, requests for both free and busy, and the associated replies. Free/Busy information is represented with the "FREEBUSY" property. This property provides a terse representation of time periods. One or more "FREEBUSY" properties can be specified in the "VFREEBUSY" calendar component. When present in a "VFREEBUSY" calendar component, the "DTSTART" and "DTEND" properties SHOULD be specified prior to any "FREEBUSY" properties. In a free time request, these properties can be used in combination with the "DURATION" property to represent a request for a duration of free time within a specified window of time. The recurrence properties ("RRULE", "EXRULE", "RDATE", "EXDATE") are not permitted within a "VFREEBUSY" calendar component. Any recurring events are resolved into their individual busy time periods using the "FREEBUSY" property. Example: The following is an example of a "VFREEBUSY" calendar component used to request free or busy time information: BEGIN:VFREEBUSY ORGANIZER:MAILTO:jane_doe@host1.com ATTENDEE:MAILTO:john_public@host2.com DTSTART:19971015T050000Z DTEND:19971016T050000Z DTSTAMP:19970901T083000Z END:VFREEBUSY Dawson & Stenerson Standards Track [Page 59] RFC 2445 iCalendar November 1998 The following is an example of a "VFREEBUSY" calendar component used to reply to the request with busy time information: BEGIN:VFREEBUSY ORGANIZER:MAILTO:jane_doe@host1.com ATTENDEE:MAILTO:john_public@host2.com DTSTAMP:19970901T100000Z FREEBUSY;VALUE=PERIOD:19971015T050000Z/PT8H30M, 19971015T160000Z/PT5H30M,19971015T223000Z/PT6H30M URL:http://host2.com/pub/busy/jpublic-01.ifb COMMENT:This iCalendar file contains busy time information for the next three months. END:VFREEBUSY The following is an example of a "VFREEBUSY" calendar component used to publish busy time information. BEGIN:VFREEBUSY ORGANIZER:jsmith@host.com DTSTART:19980313T141711Z DTEND:19980410T141711Z FREEBUSY:19980314T233000Z/19980315T003000Z FREEBUSY:19980316T153000Z/19980316T163000Z FREEBUSY:19980318T030000Z/19980318T040000Z URL:http://www.host.com/calendar/busytime/jsmith.ifb END:VFREEBUSY 4.6.5 Time Zone Component Component Name: VTIMEZONE Purpose: Provide a grouping of component properties that defines a time zone. Formal Definition: A "VTIMEZONE" calendar component is defined by the following notation: timezonec = "BEGIN" ":" "VTIMEZONE" CRLF 2*( ; 'tzid' is required, but MUST NOT occur more ; than once tzid / ; 'last-mod' and 'tzurl' are optional, but MUST NOT occur more than once Dawson & Stenerson Standards Track [Page 60] RFC 2445 iCalendar November 1998 last-mod / tzurl / ; one of 'standardc' or 'daylightc' MUST occur ..; and each MAY occur more than once. standardc / daylightc / ; the following is optional, ; and MAY occur more than once x-prop ) "END" ":" "VTIMEZONE" CRLF standardc = "BEGIN" ":" "STANDARD" CRLF tzprop "END" ":" "STANDARD" CRLF daylightc = "BEGIN" ":" "DAYLIGHT" CRLF tzprop "END" ":" "DAYLIGHT" CRLF tzprop = 3*( ; the following are each REQUIRED, ; but MUST NOT occur more than once dtstart / tzoffsetto / tzoffsetfrom / ; the following are optional, ; and MAY occur more than once comment / rdate / rrule / tzname / x-prop ) Description: A time zone is unambiguously defined by the set of time measurement rules determined by the governing body for a given geographic area. These rules describe at a minimum the base offset from UTC for the time zone, often referred to as the Standard Time offset. Many locations adjust their Standard Time forward or backward by one hour, in order to accommodate seasonal changes in number of Dawson & Stenerson Standards Track [Page 61] RFC 2445 iCalendar November 1998 daylight hours, often referred to as Daylight Saving Time. Some locations adjust their time by a fraction of an hour. Standard Time is also known as Winter Time. Daylight Saving Time is also known as Advanced Time, Summer Time, or Legal Time in certain countries. The following table shows the changes in time zone rules in effect for New York City starting from 1967. Each line represents a description or rule for a particular observance. Effective Observance Rule Date (Date/Time) Offset Abbreviation 1967-* last Sun in Oct, 02:00 -0500 EST 1967-1973 last Sun in Apr, 02:00 -0400 EDT 1974-1974 Jan 6, 02:00 -0400 EDT 1975-1975 Feb 23, 02:00 -0400 EDT 1976-1986 last Sun in Apr, 02:00 -0400 EDT 1987-* first Sun in Apr, 02:00 -0400 EDT Note: The specification of a global time zone registry is not addressed by this document and is left for future study. However, implementers may find the Olson time zone database [TZ] a useful reference. It is an informal, public-domain collection of time zone information, which is currently being maintained by volunteer Internet participants, and is used in several operating systems. This database contains current and historical time zone information for a wide variety of locations around the globe; it provides a time zone identifier for every unique time zone rule set in actual use since 1970, with historical data going back to the introduction of standard time. Interoperability between two calendaring and scheduling applications, especially for recurring events, to-dos or journal entries, is dependent on the ability to capture and convey date and time information in an unambiguous format. The specification of current time zone information is integral to this behavior. If present, the "VTIMEZONE" calendar component defines the set of Standard Time and Daylight Saving Time observances (or rules) for a particular time zone for a given interval of time. The "VTIMEZONE" calendar component cannot be nested within other calendar components. Multiple "VTIMEZONE" calendar components can exist in an iCalendar object. In this situation, each "VTIMEZONE" MUST represent a unique Dawson & Stenerson Standards Track [Page 62] RFC 2445 iCalendar November 1998 time zone definition. This is necessary for some classes of events, such as airline flights, that start in one time zone and end in another. The "VTIMEZONE" calendar component MUST be present if the iCalendar object contains an RRULE that generates dates on both sides of a time zone shift (e.g. both in Standard Time and Daylight Saving Time) unless the iCalendar object intends to convey a floating time (See the section "4.1.10.11 Time" for proper interpretation of floating time). It can be present if the iCalendar object does not contain such a RRULE. In addition, if a RRULE is present, there MUST be valid time zone information for all recurrence instances. The "VTIMEZONE" calendar component MUST include the "TZID" property and at least one definition of a standard or daylight component. The standard or daylight component MUST include the "DTSTART", "TZOFFSETFROM" and "TZOFFSETTO" properties. An individual "VTIMEZONE" calendar component MUST be specified for each unique "TZID" parameter value specified in the iCalendar object. Each "VTIMEZONE" calendar component consists of a collection of one or more sub-components that describe the rule for a particular observance (either a Standard Time or a Daylight Saving Time observance). The "STANDARD" sub-component consists of a collection of properties that describe Standard Time. The "DAYLIGHT" sub-component consists of a collection of properties that describe Daylight Saving Time. In general this collection of properties consists of: - the first onset date-time for the observance - the last onset date-time for the observance, if a last onset is known. - the offset to be applied for the observance - a rule that describes the day and time when the observance takes effect - an optional name for the observance For a given time zone, there may be multiple unique definitions of the observances over a period of time. Each observance is described using either a "STANDARD" or "DAYLIGHT" sub-component. The collection of these sub-components is used to describe the time zone for a given period of time. The offset to apply at any given time is found by locating the observance that has the last onset date and time before the time in question, and using the offset value from that Dawson & Stenerson Standards Track [Page 63] RFC 2445 iCalendar November 1998 observance. The top-level properties in a "VTIMEZONE" calendar component are: The mandatory "TZID" property is a text value that uniquely identifies the VTIMZONE calendar component within the scope of an iCalendar object. The optional "LAST-MODIFIED" property is a UTC value that specifies the date and time that this time zone definition was last updated. The optional "TZURL" property is url value that points to a published VTIMEZONE definition. TZURL SHOULD refer to a resource that is accessible by anyone who might need to interpret the object. This SHOULD NOT normally be a file: URL or other URL that is not widely- accessible. The collection of properties that are used to define the STANDARD and DAYLIGHT sub-components include: The mandatory "DTSTART" property gives the effective onset date and local time for the time zone sub-component definition. "DTSTART" in this usage MUST be specified as a local DATE-TIME value. The mandatory "TZOFFSETFROM" property gives the UTC offset which is in use when the onset of this time zone observance begins. "TZOFFSETFROM" is combined with "DTSTART" to define the effective onset for the time zone sub-component definition. For example, the following represents the time at which the observance of Standard Time took effect in Fall 1967 for New York City: DTSTART:19671029T020000 TZOFFSETFROM:-0400 The mandatory "TZOFFSETTO " property gives the UTC offset for the time zone sub-component (Standard Time or Daylight Saving Time) when this observance is in use. The optional "TZNAME" property is the customary name for the time zone. It may be specified multiple times, to allow for specifying multiple language variants of the time zone names. This could be used for displaying dates. If specified, the onset for the observance defined by the time zone sub-component is defined by either the "RRULE" or "RDATE" property. If neither is specified, only one sub-component can be specified in the "VTIMEZONE" calendar component and it is assumed that the single Dawson & Stenerson Standards Track [Page 64] RFC 2445 iCalendar November 1998 observance specified is always in effect. The "RRULE" property defines the recurrence rule for the onset of the observance defined by this time zone sub-component. Some specific requirements for the usage of RRULE for this purpose include: - If observance is known to have an effective end date, the "UNTIL" recurrence rule parameter MUST be used to specify the last valid onset of this observance (i.e., the UNTIL date-time will be equal to the last instance generated by the recurrence pattern). It MUST be specified in UTC time. - The "DTSTART" and the "TZOFFSETTO" properties MUST be used when generating the onset date-time values (instances) from the RRULE. Alternatively, the "RDATE" property can be used to define the onset of the observance by giving the individual onset date and times. "RDATE" in this usage MUST be specified as a local DATE-TIME value in UTC time. The optional "COMMENT" property is also allowed for descriptive explanatory text. Example: The following are examples of the "VTIMEZONE" calendar component: This is an example showing time zone information for the Eastern United States using "RDATE" property. Note that this is only suitable for a recurring event that starts on or later than April 6, 1997 at 03:00:00 EDT (i.e., the earliest effective transition date and time) and ends no later than April 7, 1998 02:00:00 EST (i.e., latest valid date and time for EST in this scenario). For example, this can be used for a recurring event that occurs every Friday, 8am-9:00 AM, starting June 1, 1997, ending December 31, 1997. BEGIN:VTIMEZONE TZID:US-Eastern LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:19971026T020000 RDATE:19971026T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST END:STANDARD BEGIN:DAYLIGHT DTSTART:19971026T020000 Dawson & Stenerson Standards Track [Page 65] RFC 2445 iCalendar November 1998 RDATE:19970406T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT END:DAYLIGHT END:VTIMEZONE This is a simple example showing the current time zone rules for the Eastern United States using a RRULE recurrence pattern. Note that there is no effective end date to either of the Standard Time or Daylight Time rules. This information would be valid for a recurring event starting today and continuing indefinitely. BEGIN:VTIMEZONE TZID:US-Eastern LAST-MODIFIED:19870101T000000Z TZURL:http://zones.stds_r_us.net/tz/US-Eastern BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT END:DAYLIGHT END:VTIMEZONE This is an example showing a fictitious set of rules for the Eastern United States, where the Daylight Time rule has an effective end date (i.e., after that date, Daylight Time is no longer observed). BEGIN:VTIMEZONE TZID:US--Fictitious-Eastern LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST END:STANDARD Dawson & Stenerson Standards Track [Page 66] RFC 2445 iCalendar November 1998 BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT END:DAYLIGHT END:VTIMEZONE This is an example showing a fictitious set of rules for the Eastern United States, where the first Daylight Time rule has an effective end date. There is a second Daylight Time rule that picks up where the other left off. BEGIN:VTIMEZONE TZID:US--Fictitious-Eastern LAST-MODIFIED:19870101T000000Z BEGIN:STANDARD DTSTART:19671029T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4;UNTIL=19980404T070000Z TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT END:DAYLIGHT BEGIN:DAYLIGHT DTSTART:19990424T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=4 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT END:DAYLIGHT END:VTIMEZONE 4.6.6 Alarm Component Component Name: VALARM Purpose: Provide a grouping of component properties that define an alarm. Dawson & Stenerson Standards Track [Page 67] RFC 2445 iCalendar November 1998 Formal Definition: A "VALARM" calendar component is defined by the following notation: alarmc = "BEGIN" ":" "VALARM" CRLF (audioprop / dispprop / emailprop / procprop) "END" ":" "VALARM" CRLF audioprop = 2*( ; 'action' and 'trigger' are both REQUIRED, ; but MUST NOT occur more than once action / trigger / ; 'duration' and 'repeat' are both optional, ; and MUST NOT occur more than once each, ; but if one occurs, so MUST the other duration / repeat / ; the following is optional, ; but MUST NOT occur more than once attach / ; the following is optional, ; and MAY occur more than once x-prop ) dispprop = 3*( ; the following are all REQUIRED, ; but MUST NOT occur more than once action / description / trigger / ; 'duration' and 'repeat' are both optional, ; and MUST NOT occur more than once each, ; but if one occurs, so MUST the other duration / repeat / ; the following is optional, Dawson & Stenerson Standards Track [Page 68] RFC 2445 iCalendar November 1998 ; and MAY occur more than once *x-prop ) emailprop = 5*( ; the following are all REQUIRED, ; but MUST NOT occur more than once action / description / trigger / summary ; the following is REQUIRED, ; and MAY occur more than once attendee / ; 'duration' and 'repeat' are both optional, ; and MUST NOT occur more than once each, ; but if one occurs, so MUST the other duration / repeat / ; the following are optional, ; and MAY occur more than once attach / x-prop ) procprop = 3*( ; the following are all REQUIRED, ; but MUST NOT occur more than once action / attach / trigger / ; 'duration' and 'repeat' are both optional, ; and MUST NOT occur more than once each, ; but if one occurs, so MUST the other duration / repeat / Dawson & Stenerson Standards Track [Page 69] RFC 2445 iCalendar November 1998 ; 'description' is optional, ; and MUST NOT occur more than once description / ; the following is optional, ; and MAY occur more than once x-prop ) Description: A "VALARM" calendar component is a grouping of component properties that is a reminder or alarm for an event or a to-do. For example, it may be used to define a reminder for a pending event or an overdue to-do. The "VALARM" calendar component MUST include the "ACTION" and "TRIGGER" properties. The "ACTION" property further constrains the "VALARM" calendar component in the following ways: When the action is "AUDIO", the alarm can also include one and only one "ATTACH" property, which MUST point to a sound resource, which is rendered when the alarm is triggered. When the action is "DISPLAY", the alarm MUST also include a "DESCRIPTION" property, which contains the text to be displayed when the alarm is triggered. When the action is "EMAIL", the alarm MUST include a "DESCRIPTION" property, which contains the text to be used as the message body, a "SUMMARY" property, which contains the text to be used as the message subject, and one or more "ATTENDEE" properties, which contain the email address of attendees to receive the message. It can also include one or more "ATTACH" properties, which are intended to be sent as message attachments. When the alarm is triggered, the email message is sent. When the action is "PROCEDURE", the alarm MUST include one and only one "ATTACH" property, which MUST point to a procedure resource, which is invoked when the alarm is triggered. The "VALARM" calendar component MUST only appear within either a "VEVENT" or "VTODO" calendar component. "VALARM" calendar components cannot be nested. Multiple mutually independent "VALARM" calendar components can be specified for a single "VEVENT" or "VTODO" calendar component. Dawson & Stenerson Standards Track [Page 70] RFC 2445 iCalendar November 1998 The "TRIGGER" property specifies when the alarm will be triggered. The "TRIGGER" property specifies a duration prior to the start of an event or a to-do. The "TRIGGER" edge may be explicitly set to be relative to the "START" or "END" of the event or to-do with the "RELATED" parameter of the "TRIGGER" property. The "TRIGGER" property value type can alternatively be set to an absolute calendar date and time of day value. In an alarm set to trigger on the "START" of an event or to-do, the "DTSTART" property MUST be present in the associated event or to-do. In an alarm in a "VEVENT" calendar component set to trigger on the "END" of the event, either the "DTEND" property MUST be present, or the "DTSTART" and "DURATION" properties MUST both be present. In an alarm in a "VTODO" calendar component set to trigger on the "END" of the to-do, either the "DUE" property MUST be present, or the "DTSTART" and "DURATION" properties MUST both be present. The alarm can be defined such that it triggers repeatedly. A definition of an alarm with a repeating trigger MUST include both the "DURATION" and "REPEAT" properties. The "DURATION" property specifies the delay period, after which the alarm will repeat. The "REPEAT" property specifies the number of additional repetitions that the alarm will triggered. This repitition count is in addition to the initial triggering of the alarm. Both of these properties MUST be present in order to specify a repeating alarm. If one of these two properties is absent, then the alarm will not repeat beyond the initial trigger. The "ACTION" property is used within the "VALARM" calendar component to specify the type of action invoked when the alarm is triggered. The "VALARM" properties provide enough information for a specific action to be invoked. It is typically the responsibility of a "Calendar User Agent" (CUA) to deliver the alarm in the specified fashion. An "ACTION" property value of AUDIO specifies an alarm that causes a sound to be played to alert the user; DISPLAY specifies an alarm that causes a text message to be displayed to the user; EMAIL specifies an alarm that causes an electronic email message to be delivered to one or more email addresses; and PROCEDURE specifies an alarm that causes a procedure to be executed. The "ACTION" property MUST specify one and only one of these values. In an AUDIO alarm, if the optional "ATTACH" property is included, it MUST specify an audio sound resource. The intention is that the sound will be played as the alarm effect. If an "ATTACH" property is specified that does not refer to a sound resource, or if the specified sound resource cannot be rendered (because its format is unsupported, or because it cannot be retrieved), then the CUA or other entity responsible for playing the sound may choose a fallback Dawson & Stenerson Standards Track [Page 71] RFC 2445 iCalendar November 1998 action, such as playing a built-in default sound, or playing no sound at all. In a DISPLAY alarm, the intended alarm effect is for the text value of the "DESCRIPTION" property to be displayed to the user. In an EMAIL alarm, the intended alarm effect is for an email message to be composed and delivered to all the addresses specified by the "ATTENDEE" properties in the "VALARM" calendar component. The "DESCRIPTION" property of the "VALARM" calendar component MUST be used as the body text of the message, and the "SUMMARY" property MUST be used as the subject text. Any "ATTACH" properties in the "VALARM" calendar component SHOULD be sent as attachments to the message. In a PROCEDURE alarm, the "ATTACH" property in the "VALARM" calendar component MUST specify a procedure or program that is intended to be invoked as the alarm effect. If the procedure or program is in a format that cannot be rendered, then no procedure alarm will be invoked. If the "DESCRIPTION" property is present, its value specifies the argument string to be passed to the procedure or program. "Calendar User Agents" that receive an iCalendar object with this category of alarm, can disable or allow the "Calendar User" to disable, or otherwise ignore this type of alarm. While a very useful alarm capability, the PROCEDURE type of alarm SHOULD be treated by the "Calendar User Agent" as a potential security risk. Example: The following example is for a "VALARM" calendar component that specifies an audio alarm that will sound at a precise time and repeat 4 more times at 15 minute intervals: BEGIN:VALARM TRIGGER;VALUE=DATE-TIME:19970317T133000Z REPEAT:4 DURATION:PT15M ACTION:AUDIO ATTACH;FMTTYPE=audio/basic:ftp://host.com/pub/sounds/bell-01.aud END:VALARM The following example is for a "VALARM" calendar component that specifies a display alarm that will trigger 30 minutes before the scheduled start of the event or the due date/time of the to-do it is associated with and will repeat 2 more times at 15 minute intervals: BEGIN:VALARM TRIGGER:-PT30M REPEAT:2 DURATION:PT15M ACTION:DISPLAY Dawson & Stenerson Standards Track [Page 72] RFC 2445 iCalendar November 1998 DESCRIPTION:Breakfast meeting with executive\n team at 8:30 AM EST. END:VALARM The following example is for a "VALARM" calendar component that specifies an email alarm that will trigger 2 days before the scheduled due date/time of a to-do it is associated with. It does not repeat. The email has a subject, body and attachment link. BEGIN:VALARM TRIGGER:-P2D ACTION:EMAIL ATTENDEE:MAILTO:john_doe@host.com SUMMARY:*** REMINDER: SEND AGENDA FOR WEEKLY STAFF MEETING *** DESCRIPTION:A draft agenda needs to be sent out to the attendees to the weekly managers meeting (MGR-LIST). Attached is a pointer the document template for the agenda file. ATTACH;FMTTYPE=application/binary:http://host.com/templates/agen da.doc END:VALARM The following example is for a "VALARM" calendar component that specifies a procedural alarm that will trigger at a precise date/time and will repeat 23 more times at one hour intervals. The alarm will invoke a procedure file. BEGIN:VALARM TRIGGER;VALUE=DATE-TIME:19980101T050000Z REPEAT:23 DURATION:PT1H ACTION:PROCEDURE ATTACH;FMTTYPE=application/binary:ftp://host.com/novo- procs/felizano.exe END:VALARM 4.7 Calendar Properties The Calendar Properties are attributes that apply to the iCalendar object, as a whole. These properties do not appear within a calendar component. They SHOULD be specified after the "BEGIN:VCALENDAR" property and prior to any calendar component. 4.7.1 Calendar Scale Property Name: CALSCALE Purpose: This property defines the calendar scale used for the calendar information specified in the iCalendar object. Dawson & Stenerson Standards Track [Page 73] RFC 2445 iCalendar November 1998 Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: Property can be specified in an iCalendar object. The default value is "GREGORIAN". Description: This memo is based on the Gregorian calendar scale. The Gregorian calendar scale is assumed if this property is not specified in the iCalendar object. It is expected that other calendar scales will be defined in other specifications or by future versions of this memo. Format Definition: The property is defined by the following notation: calscale = "CALSCALE" calparam ":" calvalue CRLF calparam = *(";" xparam) calvalue = "GREGORIAN" / iana-token Example: The following is an example of this property: CALSCALE:GREGORIAN 4.7.2 Method Property Name: METHOD Purpose: This property defines the iCalendar object method associated with the calendar object. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property can be specified in an iCalendar object. Description: When used in a MIME message entity, the value of this property MUST be the same as the Content-Type "method" parameter value. This property can only appear once within the iCalendar object. If either the "METHOD" property or the Content-Type "method" parameter is specified, then the other MUST also be specified. No methods are defined by this specification. This is the subject of other specifications, such as the iCalendar Transport-independent Dawson & Stenerson Standards Track [Page 74] RFC 2445 iCalendar November 1998 Interoperability Protocol (iTIP) defined by [ITIP]. If this property is not present in the iCalendar object, then a scheduling transaction MUST NOT be assumed. In such cases, the iCalendar object is merely being used to transport a snapshot of some calendar information; without the intention of conveying a scheduling semantic. Format Definition: The property is defined by the following notation: method = "METHOD" metparam ":" metvalue CRLF metparam = *(";" xparam) metvalue = iana-token Example: The following is a hypothetical example of this property to convey that the iCalendar object is a request for a meeting: METHOD:REQUEST 4.7.3 Product Identifier Property Name: PRODID Purpose: This property specifies the identifier for the product that created the iCalendar object. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property MUST be specified once in an iCalendar object. Description: The vendor of the implementation SHOULD assure that this is a globally unique identifier; using some technique such as an FPI value, as defined in [ISO 9070]. This property SHOULD not be used to alter the interpretation of an iCalendar object beyond the semantics specified in this memo. For example, it is not to be used to further the understanding of non- standard properties. Format Definition: The property is defined by the following notation: prodid = "PRODID" pidparam ":" pidvalue CRLF Dawson & Stenerson Standards Track [Page 75] RFC 2445 iCalendar November 1998 pidparam = *(";" xparam) pidvalue = text ;Any text that describes the product and version ;and that is generally assured of being unique. Example: The following is an example of this property. It does not imply that English is the default language. PRODID:-//ABC Corporation//NONSGML My Product//EN 4.7.4 Version Property Name: VERSION Purpose: This property specifies the identifier corresponding to the highest version number or the minimum and maximum range of the iCalendar specification that is required in order to interpret the iCalendar object. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST be specified by an iCalendar object, but MUST only be specified once. Description: A value of "2.0" corresponds to this memo. Format Definition: The property is defined by the following notation: version = "VERSION" verparam ":" vervalue CRLF verparam = *(";" xparam) vervalue = "2.0" ;This memo / maxver / (minver ";" maxver) minver = ;Minimum iCalendar version needed to parse the iCalendar object maxver = ;Maximum iCalendar version needed to parse the iCalendar object Example: The following is an example of this property: Dawson & Stenerson Standards Track [Page 76] RFC 2445 iCalendar November 1998 VERSION:2.0 4.8 Component Properties The following properties can appear within calendar components, as specified by each component property definition. 4.8.1 Descriptive Component Properties The following properties specify descriptive information about calendar components. 4.8.1.1 Attachment Property Name: ATTACH Purpose: The property provides the capability to associate a document object with a calendar component. Value Type: The default value type for this property is URI. The value type can also be set to BINARY to indicate inline binary encoded content information. Property Parameters: Non-standard, inline encoding, format type and value data type property parameters can be specified on this property. Conformance: The property can be specified in a "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar components. Description: The property can be specified within "VEVENT", "VTODO", "VJOURNAL", or "VALARM" calendar components. This property can be specified multiple times within an iCalendar object. Format Definition: The property is defined by the following notation: attach = "ATTACH" attparam ":" uri CRLF attach =/ "ATTACH" attparam ";" "ENCODING" "=" "BASE64" ";" "VALUE" "=" "BINARY" ":" binary attparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" fmttypeparam) / Dawson & Stenerson Standards Track [Page 77] RFC 2445 iCalendar November 1998 ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are examples of this property: ATTACH:CID:jsmith.part3.960817T083000.xyzMail@host1.com ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/ reports/r-960812.ps 4.8.1.2 Categories Property Name: CATEGORIES Purpose: This property defines the categories for a calendar component. Value Type: TEXT Property Parameters: Non-standard and language property parameters can be specified on this property. Conformance: The property can be specified within "VEVENT", "VTODO" or "VJOURNAL" calendar components. Description: This property is used to specify categories or subtypes of the calendar component. The categories are useful in searching for a calendar component of a particular type and category. Within the "VEVENT", "VTODO" or "VJOURNAL" calendar components, more than one category can be specified as a list of categories separated by the COMMA character (US-ASCII decimal 44). Format Definition: The property is defined by the following notation: categories = "CATEGORIES" catparam ":" text *("," text) CRLF catparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" languageparam ) / Dawson & Stenerson Standards Track [Page 78] RFC 2445 iCalendar November 1998 ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are examples of this property: CATEGORIES:APPOINTMENT,EDUCATION CATEGORIES:MEETING 4.8.1.3 Classification Property Name: CLASS Purpose: This property defines the access classification for a calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property can be specified once in a "VEVENT", "VTODO" or "VJOURNAL" calendar components. Description: An access classification is only one component of the general security system within a calendar application. It provides a method of capturing the scope of the access the calendar owner intends for information within an individual calendar entry. The access classification of an individual iCalendar component is useful when measured along with the other security components of a calendar system (e.g., calendar user authentication, authorization, access rights, access role, etc.). Hence, the semantics of the individual access classifications cannot be completely defined by this memo alone. Additionally, due to the "blind" nature of most exchange processes using this memo, these access classifications cannot serve as an enforcement statement for a system receiving an iCalendar object. Rather, they provide a method for capturing the intention of the calendar owner for the access to the calendar component. Format Definition: The property is defined by the following notation: class = "CLASS" classparam ":" classvalue CRLF classparam = *(";" xparam) Dawson & Stenerson Standards Track [Page 79] RFC 2445 iCalendar November 1998 classvalue = "PUBLIC" / "PRIVATE" / "CONFIDENTIAL" / iana-token / x-name ;Default is PUBLIC Example: The following is an example of this property: CLASS:PUBLIC 4.8.1.4 Comment Property Name: COMMENT Purpose: This property specifies non-processing information intended to provide a comment to the calendar user. Value Type: TEXT Property Parameters: Non-standard, alternate text representation and language property parameters can be specified on this property. Conformance: This property can be specified in "VEVENT", "VTODO", "VJOURNAL", "VTIMEZONE" or "VFREEBUSY" calendar components. Description: The property can be specified multiple times. Format Definition: The property is defined by the following notation: comment = "COMMENT" commparam ":" text CRLF commparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" altrepparam) / (";" languageparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following is an example of this property: COMMENT:The meeting really needs to include both ourselves and the customer. We can't hold this meeting without them. As a matter of fact\, the venue for the meeting ought to be at Dawson & Stenerson Standards Track [Page 80] RFC 2445 iCalendar November 1998 their site. - - John The data type for this property is TEXT. 4.8.1.5 Description Property Name: DESCRIPTION Purpose: This property provides a more complete description of the calendar component, than that provided by the "SUMMARY" property. Value Type: TEXT Property Parameters: Non-standard, alternate text representation and language property parameters can be specified on this property. Conformance: The property can be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar components. The property can be specified multiple times only within a "VJOURNAL" calendar component. Description: This property is used in the "VEVENT" and "VTODO" to capture lengthy textual decriptions associated with the activity. This property is used in the "VJOURNAL" calendar component to capture one more textual journal entries. This property is used in the "VALARM" calendar component to capture the display text for a DISPLAY category of alarm, to capture the body text for an EMAIL category of alarm and to capture the argument string for a PROCEDURE category of alarm. Format Definition: The property is defined by the following notation: description = "DESCRIPTION" descparam ":" text CRLF descparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" altrepparam) / (";" languageparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Dawson & Stenerson Standards Track [Page 81] RFC 2445 iCalendar November 1998 Example: The following is an example of the property with formatted line breaks in the property value: DESCRIPTION:Meeting to provide technical review for "Phoenix" design.\n Happy Face Conference Room. Phoenix design team MUST attend this meeting.\n RSVP to team leader. The following is an example of the property with folding of long lines: DESCRIPTION:Last draft of the new novel is to be completed for the editor's proof today. 4.8.1.6 Geographic Position Property Name: GEO Purpose: This property specifies information related to the global position for the activity specified by a calendar component. Value Type: FLOAT. The value MUST be two SEMICOLON separated FLOAT values. Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VEVENT" or "VTODO" calendar components. Description: The property value specifies latitude and longitude, in that order (i.e., "LAT LON" ordering). The longitude represents the location east or west of the prime meridian as a positive or negative real number, respectively. The longitude and latitude values MAY be specified up to six decimal places, which will allow for accuracy to within one meter of geographical position. Receiving applications MUST accept values of this precision and MAY truncate values of greater precision. Values for latitude and longitude shall be expressed as decimal fractions of degrees. Whole degrees of latitude shall be represented by a two-digit decimal number ranging from 0 through 90. Whole degrees of longitude shall be represented by a decimal number ranging from 0 through 180. When a decimal fraction of a degree is specified, it shall be separated from the whole number of degrees by a decimal point. Dawson & Stenerson Standards Track [Page 82] RFC 2445 iCalendar November 1998 Latitudes north of the equator shall be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the digits designating degrees. Latitudes south of the Equator shall be designated by a minus sign (-) preceding the digits designating degrees. A point on the Equator shall be assigned to the Northern Hemisphere. Longitudes east of the prime meridian shall be specified by a plus sign (+), or by the absence of a minus sign (-), preceding the digits designating degrees. Longitudes west of the meridian shall be designated by minus sign (-) preceding the digits designating degrees. A point on the prime meridian shall be assigned to the Eastern Hemisphere. A point on the 180th meridian shall be assigned to the Western Hemisphere. One exception to this last convention is permitted. For the special condition of describing a band of latitude around the earth, the East Bounding Coordinate data element shall be assigned the value +180 (180) degrees. Any spatial address with a latitude of +90 (90) or -90 degrees will specify the position at the North or South Pole, respectively. The component for longitude may have any legal value. With the exception of the special condition described above, this form is specified in Department of Commerce, 1986, Representation of geographic point locations for information interchange (Federal Information Processing Standard 70-1): Washington, Department of Commerce, National Institute of Standards and Technology. The simple formula for converting degrees-minutes-seconds into decimal degrees is: decimal = degrees + minutes/60 + seconds/3600. Format Definition: The property is defined by the following notation: geo = "GEO" geoparam ":" geovalue CRLF geoparam = *(";" xparam) geovalue = float ";" float ;Latitude and Longitude components Example: The following is an example of this property: GEO:37.386013;-122.082932 Dawson & Stenerson Standards Track [Page 83] RFC 2445 iCalendar November 1998 4.8.1.7 Location Property Name: LOCATION Purpose: The property defines the intended venue for the activity defined by a calendar component. Value Type: TEXT Property Parameters: Non-standard, alternate text representation and language property parameters can be specified on this property. Conformance: This property can be specified in "VEVENT" or "VTODO" calendar component. Description: Specific venues such as conference or meeting rooms may be explicitly specified using this property. An alternate representation may be specified that is a URI that points to directory information with more structured specification of the location. For example, the alternate representation may specify either an LDAP URI pointing to an LDAP server entry or a CID URI pointing to a MIME body part containing a vCard [RFC 2426] for the location. Format Definition: The property is defined by the following notation: location = "LOCATION locparam ":" text CRLF locparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" altrepparam) / (";" languageparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are some examples of this property: LOCATION:Conference Room - F123\, Bldg. 002 LOCATION;ALTREP="http://xyzcorp.com/conf-rooms/f123.vcf": Conference Room - F123\, Bldg. 002 Dawson & Stenerson Standards Track [Page 84] RFC 2445 iCalendar November 1998 4.8.1.8 Percent Complete Property Name: PERCENT-COMPLETE Purpose: This property is used by an assignee or delegatee of a to-do to convey the percent completion of a to-do to the Organizer. Value Type: INTEGER Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in a "VTODO" calendar component. Description: The property value is a positive integer between zero and one hundred. A value of "0" indicates the to-do has not yet been started. A value of "100" indicates that the to-do has been completed. Integer values in between indicate the percent partially complete. When a to-do is assigned to multiple individuals, the property value indicates the percent complete for that portion of the to-do assigned to the assignee or delegatee. For example, if a to-do is assigned to both individuals "A" and "B". A reply from "A" with a percent complete of "70" indicates that "A" has completed 70% of the to-do assigned to them. A reply from "B" with a percent complete of "50" indicates "B" has completed 50% of the to-do assigned to them. Format Definition: The property is defined by the following notation: percent = "PERCENT-COMPLETE" pctparam ":" integer CRLF pctparam = *(";" xparam) Example: The following is an example of this property to show 39% completion: PERCENT-COMPLETE:39 4.8.1.9 Priority Property Name: PRIORITY Purpose: The property defines the relative priority for a calendar component. Value Type: INTEGER Dawson & Stenerson Standards Track [Page 85] RFC 2445 iCalendar November 1998 Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property can be specified in a "VEVENT" or "VTODO" calendar component. Description: The priority is specified as an integer in the range zero to nine. A value of zero (US-ASCII decimal 48) specifies an undefined priority. A value of one (US-ASCII decimal 49) is the highest priority. A value of two (US-ASCII decimal 50) is the second highest priority. Subsequent numbers specify a decreasing ordinal priority. A value of nine (US-ASCII decimal 58) is the lowest priority. A CUA with a three-level priority scheme of "HIGH", "MEDIUM" and "LOW" is mapped into this property such that a property value in the range of one (US-ASCII decimal 49) to four (US-ASCII decimal 52) specifies "HIGH" priority. A value of five (US-ASCII decimal 53) is the normal or "MEDIUM" priority. A value in the range of six (US- ASCII decimal 54) to nine (US-ASCII decimal 58) is "LOW" priority. A CUA with a priority schema of "A1", "A2", "A3", "B1", "B2", ..., "C3" is mapped into this property such that a property value of one (US-ASCII decimal 49) specifies "A1", a property value of two (US- ASCII decimal 50) specifies "A2", a property value of three (US-ASCII decimal 51) specifies "A3", and so forth up to a property value of 9 (US-ASCII decimal 58) specifies "C3". Other integer values are reserved for future use. Within a "VEVENT" calendar component, this property specifies a priority for the event. This property may be useful when more than one event is scheduled for a given time period. Within a "VTODO" calendar component, this property specified a priority for the to-do. This property is useful in prioritizing multiple action items for a given time period. Format Definition: The property is specified by the following notation: priority = "PRIORITY" prioparam ":" privalue CRLF ;Default is zero prioparam = *(";" xparam) privalue = integer ;Must be in the range [0..9] ; All other values are reserved for future use Dawson & Stenerson Standards Track [Page 86] RFC 2445 iCalendar November 1998 The following is an example of a property with the highest priority: PRIORITY:1 The following is an example of a property with a next highest priority: PRIORITY:2 Example: The following is an example of a property with no priority. This is equivalent to not specifying the "PRIORITY" property: PRIORITY:0 4.8.1.10 Resources Property Name: RESOURCES Purpose: This property defines the equipment or resources anticipated for an activity specified by a calendar entity.. Value Type: TEXT Property Parameters: Non-standard, alternate text representation and language property parameters can be specified on this property. Conformance: This property can be specified in "VEVENT" or "VTODO" calendar component. Description: The property value is an arbitrary text. More than one resource can be specified as a list of resources separated by the COMMA character (US-ASCII decimal 44). Format Definition: The property is defined by the following notation: resources = "RESOURCES" resrcparam ":" text *("," text) CRLF resrcparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" altrepparam) / (";" languageparam) / ; the following is optional, ; and MAY occur more than once Dawson & Stenerson Standards Track [Page 87] RFC 2445 iCalendar November 1998 (";" xparam) ) Example: The following is an example of this property: RESOURCES:EASEL,PROJECTOR,VCR RESOURCES;LANGUAGE=fr:1 raton-laveur 4.8.1.11 Status Property Name: STATUS Purpose: This property defines the overall status or confirmation for the calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VEVENT", "VTODO" or "VJOURNAL" calendar components. Description: In a group scheduled calendar component, the property is used by the "Organizer" to provide a confirmation of the event to the "Attendees". For example in a "VEVENT" calendar component, the "Organizer" can indicate that a meeting is tentative, confirmed or cancelled. In a "VTODO" calendar component, the "Organizer" can indicate that an action item needs action, is completed, is in process or being worked on, or has been cancelled. In a "VJOURNAL" calendar component, the "Organizer" can indicate that a journal entry is draft, final or has been cancelled or removed. Format Definition: The property is defined by the following notation: status = "STATUS" statparam] ":" statvalue CRLF statparam = *(";" xparam) statvalue = "TENTATIVE" ;Indicates event is ;tentative. / "CONFIRMED" ;Indicates event is ;definite. / "CANCELLED" ;Indicates event was ;cancelled. ;Status values for a "VEVENT" Dawson & Stenerson Standards Track [Page 88] RFC 2445 iCalendar November 1998 statvalue =/ "NEEDS-ACTION" ;Indicates to-do needs action. / "COMPLETED" ;Indicates to-do completed. / "IN-PROCESS" ;Indicates to-do in process of / "CANCELLED" ;Indicates to-do was cancelled. ;Status values for "VTODO". statvalue =/ "DRAFT" ;Indicates journal is draft. / "FINAL" ;Indicates journal is final. / "CANCELLED" ;Indicates journal is removed. ;Status values for "VJOURNAL". Example: The following is an example of this property for a "VEVENT" calendar component: STATUS:TENTATIVE The following is an example of this property for a "VTODO" calendar component: STATUS:NEEDS-ACTION The following is an example of this property for a "VJOURNAL" calendar component: STATUS:DRAFT 4.8.1.12 Summary Property Name: SUMMARY Purpose: This property defines a short summary or subject for the calendar component. Value Type: TEXT Property Parameters: Non-standard, alternate text representation and language property parameters can be specified on this property. Conformance: The property can be specified in "VEVENT", "VTODO", "VJOURNAL" or "VALARM" calendar components. Description: This property is used in the "VEVENT", "VTODO" and "VJOURNAL" calendar components to capture a short, one line summary about the activity or journal entry. This property is used in the "VALARM" calendar component to capture the subject of an EMAIL category of alarm. Dawson & Stenerson Standards Track [Page 89] RFC 2445 iCalendar November 1998 Format Definition: The property is defined by the following notation: summary = "SUMMARY" summparam ":" text CRLF summparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" altrepparam) / (";" languageparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following is an example of this property: SUMMARY:Department Party 4.8.2 Date and Time Component Properties The following properties specify date and time related information in calendar components. 4.8.2.1 Date/Time Completed Property Name: COMPLETED Purpose: This property defines the date and time that a to-do was actually completed. Value Type: DATE-TIME Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property can be specified in a "VTODO" calendar component. Description: The date and time MUST be in a UTC format. Format Definition: The property is defined by the following notation: completed = "COMPLETED" compparam ":" date-time CRLF Dawson & Stenerson Standards Track [Page 90] RFC 2445 iCalendar November 1998 compparam = *(";" xparam) Example: The following is an example of this property: COMPLETED:19960401T235959Z 4.8.2.2 Date/Time End Property Name: DTEND Purpose: This property specifies the date and time that a calendar component ends. Value Type: The default value type is DATE-TIME. The value type can be set to a DATE value type. Property Parameters: Non-standard, value data type, time zone identifier property parameters can be specified on this property. Conformance: This property can be specified in "VEVENT" or "VFREEBUSY" calendar components. Description: Within the "VEVENT" calendar component, this property defines the date and time by which the event ends. The value MUST be later in time than the value of the "DTSTART" property. Within the "VFREEBUSY" calendar component, this property defines the end date and time for the free or busy time information. The time MUST be specified in the UTC time format. The value MUST be later in time than the value of the "DTSTART" property. Format Definition: The property is defined by the following notation: dtend = "DTEND" dtendparam":" dtendval CRLF dtendparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / (";" tzidparam) / ; the following is optional, ; and MAY occur more than once Dawson & Stenerson Standards Track [Page 91] RFC 2445 iCalendar November 1998 (";" xparam) ) dtendval = date-time / date ;Value MUST match value type Example: The following is an example of this property: DTEND:19960401T235959Z DTEND;VALUE=DATE:19980704 4.8.2.3 Date/Time Due Property Name: DUE Purpose: This property defines the date and time that a to-do is expected to be completed. Value Type: The default value type is DATE-TIME. The value type can be set to a DATE value type. Property Parameters: Non-standard, value data type, time zone identifier property parameters can be specified on this property. Conformance: The property can be specified once in a "VTODO" calendar component. Description: The value MUST be a date/time equal to or after the DTSTART value, if specified. Format Definition: The property is defined by the following notation: due = "DUE" dueparam":" dueval CRLF dueparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / (";" tzidparam) / ; the following is optional, ; and MAY occur more than once Dawson & Stenerson Standards Track [Page 92] RFC 2445 iCalendar November 1998 *(";" xparam) ) dueval = date-time / date ;Value MUST match value type Example: The following is an example of this property: DUE:19980430T235959Z 4.8.2.4 Date/Time Start Property Name: DTSTART Purpose: This property specifies when the calendar component begins. Value Type: The default value type is DATE-TIME. The time value MUST be one of the forms defined for the DATE-TIME value type. The value type can be set to a DATE value type. Property Parameters: Non-standard, value data type, time zone identifier property parameters can be specified on this property. Conformance: This property can be specified in the "VEVENT", "VTODO", "VFREEBUSY", or "VTIMEZONE" calendar components. Description: Within the "VEVENT" calendar component, this property defines the start date and time for the event. The property is REQUIRED in "VEVENT" calendar components. Events can have a start date/time but no end date/time. In that case, the event does not take up any time. Within the "VFREEBUSY" calendar component, this property defines the start date and time for the free or busy time information. The time MUST be specified in UTC time. Within the "VTIMEZONE" calendar component, this property defines the effective start date and time for a time zone specification. This property is REQUIRED within each STANDARD and DAYLIGHT part included in "VTIMEZONE" calendar components and MUST be specified as a local DATE-TIME without the "TZID" property parameter. Format Definition: The property is defined by the following notation: dtstart = "DTSTART" dtstparam ":" dtstval CRLF Dawson & Stenerson Standards Track [Page 93] RFC 2445 iCalendar November 1998 dtstparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / (";" tzidparam) / ; the following is optional, ; and MAY occur more than once *(";" xparam) ) dtstval = date-time / date ;Value MUST match value type Example: The following is an example of this property: DTSTART:19980118T073000Z 4.8.2.5 Duration Property Name: DURATION Purpose: The property specifies a positive duration of time. Value Type: DURATION Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property can be specified in "VEVENT", "VTODO", "VFREEBUSY" or "VALARM" calendar components. Description: In a "VEVENT" calendar component the property may be used to specify a duration of the event, instead of an explicit end date/time. In a "VTODO" calendar component the property may be used to specify a duration for the to-do, instead of an explicit due date/time. In a "VFREEBUSY" calendar component the property may be used to specify the interval of free time being requested. In a "VALARM" calendar component the property may be used to specify the delay period prior to repeating an alarm. Format Definition: The property is defined by the following notation: Dawson & Stenerson Standards Track [Page 94] RFC 2445 iCalendar November 1998 duration = "DURATION" durparam ":" dur-value CRLF ;consisting of a positive duration of time. durparam = *(";" xparam) Example: The following is an example of this property that specifies an interval of time of 1 hour and zero minutes and zero seconds: DURATION:PT1H0M0S The following is an example of this property that specifies an interval of time of 15 minutes. DURATION:PT15M 4.8.2.6 Free/Busy Time Property Name: FREEBUSY Purpose: The property defines one or more free or busy time intervals. Value Type: PERIOD. The date and time values MUST be in an UTC time format. Property Parameters: Non-standard or free/busy time type property parameters can be specified on this property. Conformance: The property can be specified in a "VFREEBUSY" calendar component. Property Parameter: "FBTYPE" and non-standard parameters can be specified on this property. Description: These time periods can be specified as either a start and end date-time or a start date-time and duration. The date and time MUST be a UTC time format. "FREEBUSY" properties within the "VFREEBUSY" calendar component SHOULD be sorted in ascending order, based on start time and then end time, with the earliest periods first. The "FREEBUSY" property can specify more than one value, separated by the COMMA character (US-ASCII decimal 44). In such cases, the "FREEBUSY" property values SHOULD all be of the same "FBTYPE" property parameter type (e.g., all values of a particular "FBTYPE" listed together in a single property). Dawson & Stenerson Standards Track [Page 95] RFC 2445 iCalendar November 1998 Format Definition: The property is defined by the following notation: freebusy = "FREEBUSY" fbparam ":" fbvalue CRLF fbparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" fbtypeparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) fbvalue = period *["," period] ;Time value MUST be in the UTC time format. Example: The following are some examples of this property: FREEBUSY;FBTYPE=BUSY-UNAVAILABLE:19970308T160000Z/PT8H30M FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H FREEBUSY;FBTYPE=FREE:19970308T160000Z/PT3H,19970308T200000Z/PT1H, 19970308T230000Z/19970309T000000Z 4.8.2.7 Time Transparency Property Name: TRANSP Purpose: This property defines whether an event is transparent or not to busy time searches. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified once in a "VEVENT" calendar component. Description: Time Transparency is the characteristic of an event that determines whether it appears to consume time on a calendar. Events that consume actual time for the individual or resource associated Dawson & Stenerson Standards Track [Page 96] RFC 2445 iCalendar November 1998 with the calendar SHOULD be recorded as OPAQUE, allowing them to be detected by free-busy time searches. Other events, which do not take up the individual's (or resource's) time SHOULD be recorded as TRANSPARENT, making them invisible to free-busy time searches. Format Definition: The property is specified by the following notation: transp = "TRANSP" tranparam ":" transvalue CRLF tranparam = *(";" xparam) transvalue = "OPAQUE" ;Blocks or opaque on busy time searches. / "TRANSPARENT" ;Transparent on busy time searches. ;Default value is OPAQUE Example: The following is an example of this property for an event that is transparent or does not block on free/busy time searches: TRANSP:TRANSPARENT The following is an example of this property for an event that is opaque or blocks on free/busy time searches: TRANSP:OPAQUE 4.8.3 Time Zone Component Properties The following properties specify time zone information in calendar components. 4.8.3.1 Time Zone Identifier Property Name: TZID Purpose: This property specifies the text value that uniquely identifies the "VTIMEZONE" calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST be specified in a "VTIMEZONE" calendar component. Dawson & Stenerson Standards Track [Page 97] RFC 2445 iCalendar November 1998 Description: This is the label by which a time zone calendar component is referenced by any iCalendar properties whose data type is either DATE-TIME or TIME and not intended to specify a UTC or a "floating" time. The presence of the SOLIDUS character (US-ASCII decimal 47) as a prefix, indicates that this TZID represents an unique ID in a globally defined time zone registry (when such registry is defined). Note: This document does not define a naming convention for time zone identifiers. Implementers may want to use the naming conventions defined in existing time zone specifications such as the public-domain Olson database [TZ]. The specification of globally unique time zone identifiers is not addressed by this document and is left for future study. Format Definition: This property is defined by the following notation: tzid = "TZID" tzidpropparam ":" [tzidprefix] text CRLF tzidpropparam = *(";" xparam) ;tzidprefix = "/" ; Defined previously. Just listed here for reader convenience. Example: The following are examples of non-globally unique time zone identifiers: TZID:US-Eastern TZID:California-Los_Angeles The following is an example of a fictitious globally unique time zone identifier: TZID:/US-New_York-New_York 4.8.3.2 Time Zone Name Property Name: TZNAME Purpose: This property specifies the customary designation for a time zone description. Value Type: TEXT Property Parameters: Non-standard and language property parameters can be specified on this property. Dawson & Stenerson Standards Track [Page 98] RFC 2445 iCalendar November 1998 Conformance: This property can be specified in a "VTIMEZONE" calendar component. Description: This property may be specified in multiple languages; in order to provide for different language requirements. Format Definition: This property is defined by the following notation: tzname = "TZNAME" tznparam ":" text CRLF tznparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" languageparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are example of this property: TZNAME:EST The following is an example of this property when two different languages for the time zone name are specified: TZNAME;LANGUAGE=en:EST TZNAME;LANGUAGE=fr-CA:HNE 4.8.3.3 Time Zone Offset From Property Name: TZOFFSETFROM Purpose: This property specifies the offset which is in use prior to this time zone observance. Value Type: UTC-OFFSET Property Parameters: Non-standard property parameters can be specified on this property. Dawson & Stenerson Standards Track [Page 99] RFC 2445 iCalendar November 1998 Conformance: This property MUST be specified in a "VTIMEZONE" calendar component. Description: This property specifies the offset which is in use prior to this time observance. It is used to calculate the absolute time at which the transition to a given observance takes place. This property MUST only be specified in a "VTIMEZONE" calendar component. A "VTIMEZONE" calendar component MUST include this property. The property value is a signed numeric indicating the number of hours and possibly minutes from UTC. Positive numbers represent time zones east of the prime meridian, or ahead of UTC. Negative numbers represent time zones west of the prime meridian, or behind UTC. Format Definition: The property is defined by the following notation: tzoffsetfrom = "TZOFFSETFROM" frmparam ":" utc-offset CRLF frmparam = *(";" xparam) Example: The following are examples of this property: TZOFFSETFROM:-0500 TZOFFSETFROM:+1345 4.8.3.4 Time Zone Offset To Property Name: TZOFFSETTO Purpose: This property specifies the offset which is in use in this time zone observance. Value Type: UTC-OFFSET Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST be specified in a "VTIMEZONE" calendar component. Description: This property specifies the offset which is in use in this time zone observance. It is used to calculate the absolute time for the new observance. The property value is a signed numeric indicating the number of hours and possibly minutes from UTC. Positive numbers represent time zones east of the prime meridian, or ahead of UTC. Negative numbers represent time zones west of the prime meridian, or behind UTC. Dawson & Stenerson Standards Track [Page 100] RFC 2445 iCalendar November 1998 Format Definition: The property is defined by the following notation: tzoffsetto = "TZOFFSETTO" toparam ":" utc-offset CRLF toparam = *(";" xparam) Example: The following are examples of this property: TZOFFSETTO:-0400 TZOFFSETTO:+1245 4.8.3.5 Time Zone URL Property Name: TZURL Purpose: The TZURL provides a means for a VTIMEZONE component to point to a network location that can be used to retrieve an up-to- date version of itself. Value Type: URI Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in a "VTIMEZONE" calendar component. Description: The TZURL provides a means for a VTIMEZONE component to point to a network location that can be used to retrieve an up-to- date version of itself. This provides a hook to handle changes government bodies impose upon time zone definitions. Retrieval of this resource results in an iCalendar object containing a single VTIMEZONE component and a METHOD property set to PUBLISH. Format Definition: The property is defined by the following notation: tzurl = "TZURL" tzurlparam ":" uri CRLF tzurlparam = *(";" xparam) Example: The following is an example of this property: TZURL:http://timezones.r.us.net/tz/US-California-Los_Angeles Dawson & Stenerson Standards Track [Page 101] RFC 2445 iCalendar November 1998 4.8.4 Relationship Component Properties The following properties specify relationship information in calendar components. 4.8.4.1 Attendee Property Name: ATTENDEE Purpose: The property defines an "Attendee" within a calendar component. Value Type: CAL-ADDRESS Property Parameters: Non-standard, language, calendar user type, group or list membership, participation role, participation status, RSVP expectation, delegatee, delegator, sent by, common name or directory entry reference property parameters can be specified on this property. Conformance: This property MUST be specified in an iCalendar object that specifies a group scheduled calendar entity. This property MUST NOT be specified in an iCalendar object when publishing the calendar information (e.g., NOT in an iCalendar object that specifies the publication of a calendar user's busy time, event, to-do or journal). This property is not specified in an iCalendar object that specifies only a time zone definition or that defines calendar entities that are not group scheduled entities, but are entities only on a single user's calendar. Description: The property MUST only be specified within calendar components to specify participants, non-participants and the chair of a group scheduled calendar entity. The property is specified within an "EMAIL" category of the "VALARM" calendar component to specify an email address that is to receive the email type of iCalendar alarm. The property parameter CN is for the common or displayable name associated with the calendar address; ROLE, for the intended role that the attendee will have in the calendar component; PARTSTAT, for the status of the attendee's participation; RSVP, for indicating whether the favor of a reply is requested; CUTYPE, to indicate the type of calendar user; MEMBER, to indicate the groups that the attendee belongs to; DELEGATED-TO, to indicate the calendar users that the original request was delegated to; and DELEGATED-FROM, to indicate whom the request was delegated from; SENT-BY, to indicate whom is acting on behalf of the ATTENDEE; and DIR, to indicate the URI that points to the directory information corresponding to the attendee. These property parameters can be specified on an "ATTENDEE" Dawson & Stenerson Standards Track [Page 102] RFC 2445 iCalendar November 1998 property in either a "VEVENT", "VTODO" or "VJOURNAL" calendar component. They MUST not be specified in an "ATTENDEE" property in a "VFREEBUSY" or "VALARM" calendar component. If the LANGUAGE property parameter is specified, the identified language applies to the CN parameter. A recipient delegated a request MUST inherit the RSVP and ROLE values from the attendee that delegated the request to them. Multiple attendees can be specified by including multiple "ATTENDEE" properties within the calendar component. Format Definition: The property is defined by the following notation: attendee = "ATTENDEE" attparam ":" cal-address CRLF attparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" cutypeparam) / (";"memberparam) / (";" roleparam) / (";" partstatparam) / (";" rsvpparam) / (";" deltoparam) / (";" delfromparam) / (";" sentbyparam) / (";"cnparam) / (";" dirparam) / (";" languageparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following are examples of this property's use for a to- do: ORGANIZER:MAILTO:jsmith@host1.com ATTENDEE;MEMBER="MAILTO:DEV-GROUP@host2.com": MAILTO:joecool@host2.com ATTENDEE;DELEGATED-FROM="MAILTO:immud@host3.com": MAILTO:ildoit@host1.com The following is an example of this property used for specifying multiple attendees to an event: Dawson & Stenerson Standards Track [Page 103] RFC 2445 iCalendar November 1998 ORGANIZER:MAILTO:jsmith@host1.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;CN=Henry Cabot :MAILTO:hcabot@host2.com ATTENDEE;ROLE=REQ-PARTICIPANT;DELEGATED-FROM="MAILTO:bob@host.com" ;PARTSTAT=ACCEPTED;CN=Jane Doe:MAILTO:jdoe@host1.com The following is an example of this property with a URI to the directory information associated with the attendee: ATTENDEE;CN=John Smith;DIR="ldap://host.com:6666/o=eDABC% 20Industries,c=3DUS??(cn=3DBJim%20Dolittle)":MAILTO:jimdo@ host1.com The following is an example of this property with "delegatee" and "delegator" information for an event: ORGANIZER;CN=John Smith:MAILTO:jsmith@host.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=TENTATIVE;DELEGATED-FROM= "MAILTO:iamboss@host2.com";CN=Henry Cabot:MAILTO:hcabot@ host2.com ATTENDEE;ROLE=NON-PARTICIPANT;PARTSTAT=DELEGATED;DELEGATED-TO= "MAILTO:hcabot@host2.com";CN=The Big Cheese:MAILTO:iamboss @host2.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=ACCEPTED;CN=Jane Doe :MAILTO:jdoe@host1.com Example: The following is an example of this property's use when another calendar user is acting on behalf of the "Attendee": ATTENDEE;SENT-BY=MAILTO:jan_doe@host1.com;CN=John Smith:MAILTO: jsmith@host1.com 4.8.4.2 Contact Property Name: CONTACT Purpose: The property is used to represent contact information or alternately a reference to contact information associated with the calendar component. Value Type: TEXT Property Parameters: Non-standard, alternate text representation and language property parameters can be specified on this property. Conformance: The property can be specified in a "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar component. Dawson & Stenerson Standards Track [Page 104] RFC 2445 iCalendar November 1998 Description: The property value consists of textual contact information. An alternative representation for the property value can also be specified that refers to a URI pointing to an alternate form, such as a vCard [RFC 2426], for the contact information. Format Definition: The property is defined by the following notation: contact = "CONTACT" contparam ":" text CRLF contparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" altrepparam) / (";" languageparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following is an example of this property referencing textual contact information: CONTACT:Jim Dolittle\, ABC Industries\, +1-919-555-1234 The following is an example of this property with an alternate representation of a LDAP URI to a directory entry containing the contact information: CONTACT;ALTREP="ldap://host.com:6666/o=3DABC%20Industries\, c=3DUS??(cn=3DBJim%20Dolittle)":Jim Dolittle\, ABC Industries\, +1-919-555-1234 The following is an example of this property with an alternate representation of a MIME body part containing the contact information, such as a vCard [RFC 2426] embedded in a [MIME-DIR] content-type: CONTACT;ALTREP="CID=":Jim Dolittle\, ABC Industries\, +1-919-555-1234 The following is an example of this property referencing a network resource, such as a vCard [RFC 2426] object containing the contact information: Dawson & Stenerson Standards Track [Page 105] RFC 2445 iCalendar November 1998 CONTACT;ALTREP="http://host.com/pdi/jdoe.vcf":Jim Dolittle\, ABC Industries\, +1-919-555-1234 4.8.4.3 Organizer Property Name: ORGANIZER Purpose: The property defines the organizer for a calendar component. Value Type: CAL-ADDRESS Property Parameters: Non-standard, language, common name, directory entry reference, sent by property parameters can be specified on this property. Conformance: This property MUST be specified in an iCalendar object that specifies a group scheduled calendar entity. This property MUST be specified in an iCalendar object that specifies the publication of a calendar user's busy time. This property MUST NOT be specified in an iCalendar object that specifies only a time zone definition or that defines calendar entities that are not group scheduled entities, but are entities only on a single user's calendar. Description: The property is specified within the "VEVENT", "VTODO", "VJOURNAL calendar components to specify the organizer of a group scheduled calendar entity. The property is specified within the "VFREEBUSY" calendar component to specify the calendar user requesting the free or busy time. When publishing a "VFREEBUSY" calendar component, the property is used to specify the calendar that the published busy time came from. The property has the property parameters CN, for specifying the common or display name associated with the "Organizer", DIR, for specifying a pointer to the directory information associated with the "Organizer", SENT-BY, for specifying another calendar user that is acting on behalf of the "Organizer". The non-standard parameters may also be specified on this property. If the LANGUAGE property parameter is specified, the identified language applies to the CN parameter value. Format Definition: The property is defined by the following notation: organizer = "ORGANIZER" orgparam ":" cal-address CRLF orgparam = *( ; the following are optional, Dawson & Stenerson Standards Track [Page 106] RFC 2445 iCalendar November 1998 ; but MUST NOT occur more than once (";" cnparam) / (";" dirparam) / (";" sentbyparam) / (";" languageparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) Example: The following is an example of this property: ORGANIZER;CN=John Smith:MAILTO:jsmith@host1.com The following is an example of this property with a pointer to the directory information associated with the organizer: ORGANIZER;CN=JohnSmith;DIR="ldap://host.com:6666/o=3DDC%20Associ ates,c=3DUS??(cn=3DJohn%20Smith)":MAILTO:jsmith@host1.com The following is an example of this property used by another calendar user who is acting on behalf of the organizer, with responses intended to be sent back to the organizer, not the other calendar user: ORGANIZER;SENT-BY="MAILTO:jane_doe@host.com": MAILTO:jsmith@host1.com 4.8.4.4 Recurrence ID Property Name: RECURRENCE-ID Purpose: This property is used in conjunction with the "UID" and "SEQUENCE" property to identify a specific instance of a recurring "VEVENT", "VTODO" or "VJOURNAL" calendar component. The property value is the effective value of the "DTSTART" property of the recurrence instance. Value Type: The default value type for this property is DATE-TIME. The time format can be any of the valid forms defined for a DATE-TIME value type. See DATE-TIME value type definition for specific interpretations of the various forms. The value type can be set to DATE. Dawson & Stenerson Standards Track [Page 107] RFC 2445 iCalendar November 1998 Property Parameters: Non-standard property, value data type, time zone identifier and recurrence identifier range parameters can be specified on this property. Conformance: This property can be specified in an iCalendar object containing a recurring calendar component. Description: The full range of calendar components specified by a recurrence set is referenced by referring to just the "UID" property value corresponding to the calendar component. The "RECURRENCE-ID" property allows the reference to an individual instance within the recurrence set. If the value of the "DTSTART" property is a DATE type value, then the value MUST be the calendar date for the recurrence instance. The date/time value is set to the time when the original recurrence instance would occur; meaning that if the intent is to change a Friday meeting to Thursday, the date/time is still set to the original Friday meeting. The "RECURRENCE-ID" property is used in conjunction with the "UID" and "SEQUENCE" property to identify a particular instance of a recurring event, to-do or journal. For a given pair of "UID" and "SEQUENCE" property values, the "RECURRENCE-ID" value for a recurrence instance is fixed. When the definition of the recurrence set for a calendar component changes, and hence the "SEQUENCE" property value changes, the "RECURRENCE-ID" for a given recurrence instance might also change.The "RANGE" parameter is used to specify the effective range of recurrence instances from the instance specified by the "RECURRENCE-ID" property value. The default value for the range parameter is the single recurrence instance only. The value can also be "THISANDPRIOR" to indicate a range defined by the given recurrence instance and all prior instances or the value can be "THISANDFUTURE" to indicate a range defined by the given recurrence instance and all subsequent instances. Format Definition: The property is defined by the following notation: recurid = "RECURRENCE-ID" ridparam ":" ridval CRLF ridparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=" ("DATE-TIME" / "DATE)) / (";" tzidparam) / (";" rangeparam) / Dawson & Stenerson Standards Track [Page 108] RFC 2445 iCalendar November 1998 ; the following is optional, ; and MAY occur more than once (";" xparam) ) ridval = date-time / date ;Value MUST match value type Example: The following are examples of this property: RECURRENCE-ID;VALUE=DATE:19960401 RECURRENCE-ID;RANGE=THISANDFUTURE:19960120T120000Z 4.8.4.5 Related To Property Name: RELATED-TO Purpose: The property is used to represent a relationship or reference between one calendar component and another. Value Type: TEXT Property Parameters: Non-standard and relationship type property parameters can be specified on this property. Conformance: The property can be specified one or more times in the "VEVENT", "VTODO" or "VJOURNAL" calendar components. Description: The property value consists of the persistent, globally unique identifier of another calendar component. This value would be represented in a calendar component by the "UID" property. By default, the property value points to another calendar component that has a PARENT relationship to the referencing object. The "RELTYPE" property parameter is used to either explicitly state the default PARENT relationship type to the referenced calendar component or to override the default PARENT relationship type and specify either a CHILD or SIBLING relationship. The PARENT relationship indicates that the calendar component is a subordinate of the referenced calendar component. The CHILD relationship indicates that the calendar component is a superior of the referenced calendar component. The SIBLING relationship indicates that the calendar component is a peer of the referenced calendar component. Dawson & Stenerson Standards Track [Page 109] RFC 2445 iCalendar November 1998 Changes to a calendar component referenced by this property can have an implicit impact on the related calendar component. For example, if a group event changes its start or end date or time, then the related, dependent events will need to have their start and end dates changed in a corresponding way. Similarly, if a PARENT calendar component is canceled or deleted, then there is an implied impact to the related CHILD calendar components. This property is intended only to provide information on the relationship of calendar components. It is up to the target calendar system to maintain any property implications of this relationship. Format Definition: The property is defined by the following notation: related = "RELATED-TO" [relparam] ":" text CRLF relparam = *( ; the following is optional, ; but MUST NOT occur more than once (";" reltypeparam) / ; the following is optional, ; and MAY occur more than once (";" xparm) ) The following is an example of this property: RELATED-TO: RELATED-TO:<19960401-080045-4000F192713-0052@host1.com> 4.8.4.6 Uniform Resource Locator Property Name: URL Purpose: This property defines a Uniform Resource Locator (URL) associated with the iCalendar object. Value Type: URI Property Parameters: Non-standard property parameters can be specified on this property. Dawson & Stenerson Standards Track [Page 110] RFC 2445 iCalendar November 1998 Conformance: This property can be specified once in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. Description: This property may be used in a calendar component to convey a location where a more dynamic rendition of the calendar information associated with the calendar component can be found. This memo does not attempt to standardize the form of the URI, nor the format of the resource pointed to by the property value. If the URL property and Content-Location MIME header are both specified, they MUST point to the same resource. Format Definition: The property is defined by the following notation: url = "URL" urlparam ":" uri CRLF urlparam = *(";" xparam) Example: The following is an example of this property: URL:http://abc.com/pub/calendars/jsmith/mytime.ics 4.8.4.7 Unique Identifier Property Name: UID Purpose: This property defines the persistent, globally unique identifier for the calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property MUST be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. Description: The UID itself MUST be a globally unique identifier. The generator of the identifier MUST guarantee that the identifier is unique. There are several algorithms that can be used to accomplish this. The identifier is RECOMMENDED to be the identical syntax to the [RFC 822] addr-spec. A good method to assure uniqueness is to put the domain name or a domain literal IP address of the host on which the identifier was created on the right hand side of the "@", and on the left hand side, put a combination of the current calendar date and time of day (i.e., formatted in as a DATE-TIME value) along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number). Using a date/time value on the left hand side and a domain name or domain literal on Dawson & Stenerson Standards Track [Page 111] RFC 2445 iCalendar November 1998 the right hand side makes it possible to guarantee uniqueness since no two hosts should be using the same domain name or IP address at the same time. Though other algorithms will work, it is RECOMMENDED that the right hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can guarantee the uniqueness of the left hand side within the scope of that domain. This is the method for correlating scheduling messages with the referenced "VEVENT", "VTODO", or "VJOURNAL" calendar component. The full range of calendar components specified by a recurrence set is referenced by referring to just the "UID" property value corresponding to the calendar component. The "RECURRENCE-ID" property allows the reference to an individual instance within the recurrence set. This property is an important method for group scheduling applications to match requests with later replies, modifications or deletion requests. Calendaring and scheduling applications MUST generate this property in "VEVENT", "VTODO" and "VJOURNAL" calendar components to assure interoperability with other group scheduling applications. This identifier is created by the calendar system that generates an iCalendar object. Implementations MUST be able to receive and persist values of at least 255 characters for this property. Format Definition: The property is defined by the following notation: uid = "UID" uidparam ":" text CRLF uidparam = *(";" xparam) Example: The following is an example of this property: UID:19960401T080045Z-4000F192713-0052@host1.com 4.8.5 Recurrence Component Properties The following properties specify recurrence information in calendar components. 4.8.5.1 Exception Date/Times Property Name: EXDATE Dawson & Stenerson Standards Track [Page 112] RFC 2445 iCalendar November 1998 Purpose: This property defines the list of date/time exceptions for a recurring calendar component. Value Type: The default value type for this property is DATE-TIME. The value type can be set to DATE. Property Parameters: Non-standard, value data type and time zone identifier property parameters can be specified on this property. Conformance: This property can be specified in an iCalendar object that includes a recurring calendar component. Description: The exception dates, if specified, are used in computing the recurrence set. The recurrence set is the complete set of recurrence instances for a calendar component. The recurrence set is generated by considering the initial "DTSTART" property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained within the iCalendar object. The "DTSTART" property defines the first instance in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" properties can also be specified to define more sophisticated recurrence sets. The final recurrence set is generated by gathering all of the start date-times generated by any of the specified "RRULE" and "RDATE" properties, and then excluding any start date and times which fall within the union of start date and times generated by any specified "EXRULE" and "EXDATE" properties. This implies that start date and times within exclusion related properties (i.e., "EXDATE" and "EXRULE") take precedence over those specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are generated by the "RRULE" and "RDATE" properties, only one recurrence is considered. Duplicate instances are ignored. The "EXDATE" property can be used to exclude the value specified in "DTSTART". However, in such cases the original "DTSTART" date MUST still be maintained by the calendaring and scheduling system because the original "DTSTART" value has inherent usage dependencies by other properties such as the "RECURRENCE-ID". Format Definition: The property is defined by the following notation: exdate = "EXDATE" exdtparam ":" exdtval *("," exdtval) CRLF exdtparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=" ("DATE-TIME" / "DATE")) / Dawson & Stenerson Standards Track [Page 113] RFC 2445 iCalendar November 1998 (";" tzidparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) exdtval = date-time / date ;Value MUST match value type Example: The following is an example of this property: EXDATE:19960402T010000Z,19960403T010000Z,19960404T010000Z 4.8.5.2 Exception Rule Property Name: EXRULE Purpose: This property defines a rule or repeating pattern for an exception to a recurrence set. Value Type: RECUR Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in "VEVENT", "VTODO" or "VJOURNAL" calendar components. Description: The exception rule, if specified, is used in computing the recurrence set. The recurrence set is the complete set of recurrence instances for a calendar component. The recurrence set is generated by considering the initial "DTSTART" property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained within the iCalendar object. The "DTSTART" defines the first instance in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" properties can also be specified to define more sophisticated recurrence sets. The final recurrence set is generated by gathering all of the start date-times generated by any of the specified "RRULE" and "RDATE" properties, and excluding any start date and times which fall within the union of start date and times generated by any specified "EXRULE" and "EXDATE" properties. This implies that start date and times within exclusion related properties (i.e., "EXDATE" and "EXRULE") take precedence over those specified by inclusion Dawson & Stenerson Standards Track [Page 114] RFC 2445 iCalendar November 1998 properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are generated by the "RRULE" and "RDATE" properties, only one recurrence is considered. Duplicate instances are ignored. The "EXRULE" property can be used to exclude the value specified in "DTSTART". However, in such cases the original "DTSTART" date MUST still be maintained by the calendaring and scheduling system because the original "DTSTART" value has inherent usage dependencies by other properties such as the "RECURRENCE-ID". Format Definition: The property is defined by the following notation: exrule = "EXRULE" exrparam ":" recur CRLF exrparam = *(";" xparam) Example: The following are examples of this property. Except every other week, on Tuesday and Thursday for 4 occurrences: EXRULE:FREQ=WEEKLY;COUNT=4;INTERVAL=2;BYDAY=TU,TH Except daily for 10 occurrences: EXRULE:FREQ=DAILY;COUNT=10 Except yearly in June and July for 8 occurrences: EXRULE:FREQ=YEARLY;COUNT=8;BYMONTH=6,7 4.8.5.3 Recurrence Date/Times Property Name: RDATE Purpose: This property defines the list of date/times for a recurrence set. Value Type: The default value type for this property is DATE-TIME. The value type can be set to DATE or PERIOD. Property Parameters: Non-standard, value data type and time zone identifier property parameters can be specified on this property. Conformance: The property can be specified in "VEVENT", "VTODO", "VJOURNAL" or "VTIMEZONE" calendar components. Dawson & Stenerson Standards Track [Page 115] RFC 2445 iCalendar November 1998 Description: This property can appear along with the "RRULE" property to define an aggregate set of repeating occurrences. When they both appear in an iCalendar object, the recurring events are defined by the union of occurrences defined by both the "RDATE" and "RRULE". The recurrence dates, if specified, are used in computing the recurrence set. The recurrence set is the complete set of recurrence instances for a calendar component. The recurrence set is generated by considering the initial "DTSTART" property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained within the iCalendar object. The "DTSTART" property defines the first instance in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" properties can also be specified to define more sophisticated recurrence sets. The final recurrence set is generated by gathering all of the start date/times generated by any of the specified "RRULE" and "RDATE" properties, and excluding any start date/times which fall within the union of start date/times generated by any specified "EXRULE" and "EXDATE" properties. This implies that start date/times within exclusion related properties (i.e., "EXDATE" and "EXRULE") take precedence over those specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are generated by the "RRULE" and "RDATE" properties, only one recurrence is considered. Duplicate instances are ignored. Format Definition: The property is defined by the following notation: rdate = "RDATE" rdtparam ":" rdtval *("," rdtval) CRLF rdtparam = *( ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=" ("DATE-TIME" / "DATE" / "PERIOD")) / (";" tzidparam) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) rdtval = date-time / date / period ;Value MUST match value type Example: The following are examples of this property: Dawson & Stenerson Standards Track [Page 116] RFC 2445 iCalendar November 1998 RDATE:19970714T123000Z RDATE;TZID=US-EASTERN:19970714T083000 RDATE;VALUE=PERIOD:19960403T020000Z/19960403T040000Z, 19960404T010000Z/PT3H RDATE;VALUE=DATE:19970101,19970120,19970217,19970421 19970526,19970704,19970901,19971014,19971128,19971129,19971225 4.8.5.4 Recurrence Rule Property Name: RRULE Purpose: This property defines a rule or repeating pattern for recurring events, to-dos, or time zone definitions. Value Type: RECUR Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified one or more times in recurring "VEVENT", "VTODO" and "VJOURNAL" calendar components. It can also be specified once in each STANDARD or DAYLIGHT sub-component of the "VTIMEZONE" calendar component. Description: The recurrence rule, if specified, is used in computing the recurrence set. The recurrence set is the complete set of recurrence instances for a calendar component. The recurrence set is generated by considering the initial "DTSTART" property along with the "RRULE", "RDATE", "EXDATE" and "EXRULE" properties contained within the iCalendar object. The "DTSTART" property defines the first instance in the recurrence set. Multiple instances of the "RRULE" and "EXRULE" properties can also be specified to define more sophisticated recurrence sets. The final recurrence set is generated by gathering all of the start date/times generated by any of the specified "RRULE" and "RDATE" properties, and excluding any start date/times which fall within the union of start date/times generated by any specified "EXRULE" and "EXDATE" properties. This implies that start date/times within exclusion related properties (i.e., "EXDATE" and "EXRULE") take precedence over those specified by inclusion properties (i.e., "RDATE" and "RRULE"). Where duplicate instances are generated by the "RRULE" and "RDATE" properties, only one recurrence is considered. Duplicate instances are ignored. Dawson & Stenerson Standards Track [Page 117] RFC 2445 iCalendar November 1998 The "DTSTART" and "DTEND" property pair or "DTSTART" and "DURATION" property pair, specified within the iCalendar object defines the first instance of the recurrence. When used with a recurrence rule, the "DTSTART" and "DTEND" properties MUST be specified in local time and the appropriate set of "VTIMEZONE" calendar components MUST be included. For detail on the usage of the "VTIMEZONE" calendar component, see the "VTIMEZONE" calendar component definition. Any duration associated with the iCalendar object applies to all members of the generated recurrence set. Any modified duration for specific recurrences MUST be explicitly specified using the "RDATE" property. Format Definition: This property is defined by the following notation: rrule = "RRULE" rrulparam ":" recur CRLF rrulparam = *(";" xparam) Example: All examples assume the Eastern United States time zone. Daily for 10 occurrences: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=DAILY;COUNT=10 ==> (1997 9:00 AM EDT)September 2-11 Daily until December 24, 1997: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=DAILY;UNTIL=19971224T000000Z ==> (1997 9:00 AM EDT)September 2-30;October 1-25 (1997 9:00 AM EST)October 26-31;November 1-30;December 1-23 Every other day - forever: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=DAILY;INTERVAL=2 ==> (1997 9:00 AM EDT)September2,4,6,8...24,26,28,30; October 2,4,6...20,22,24 (1997 9:00 AM EST)October 26,28,30;November 1,3,5,7...25,27,29; Dec 1,3,... Every 10 days, 5 occurrences: Dawson & Stenerson Standards Track [Page 118] RFC 2445 iCalendar November 1998 DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=DAILY;INTERVAL=10;COUNT=5 ==> (1997 9:00 AM EDT)September 2,12,22;October 2,12 Everyday in January, for 3 years: DTSTART;TZID=US-Eastern:19980101T090000 RRULE:FREQ=YEARLY;UNTIL=20000131T090000Z; BYMONTH=1;BYDAY=SU,MO,TU,WE,TH,FR,SA or RRULE:FREQ=DAILY;UNTIL=20000131T090000Z;BYMONTH=1 ==> (1998 9:00 AM EDT)January 1-31 (1999 9:00 AM EDT)January 1-31 (2000 9:00 AM EDT)January 1-31 Weekly for 10 occurrences DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=WEEKLY;COUNT=10 ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 (1997 9:00 AM EST)October 28;November 4 Weekly until December 24, 1997 DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=WEEKLY;UNTIL=19971224T000000Z ==> (1997 9:00 AM EDT)September 2,9,16,23,30;October 7,14,21 (1997 9:00 AM EST)October 28;November 4,11,18,25; December 2,9,16,23 Every other week - forever: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;WKST=SU ==> (1997 9:00 AM EDT)September 2,16,30;October 14 (1997 9:00 AM EST)October 28;November 11,25;December 9,23 (1998 9:00 AM EST)January 6,20;February ... Weekly on Tuesday and Thursday for 5 weeks: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=WEEKLY;UNTIL=19971007T000000Z;WKST=SU;BYDAY=TU,TH or Dawson & Stenerson Standards Track [Page 119] RFC 2445 iCalendar November 1998 RRULE:FREQ=WEEKLY;COUNT=10;WKST=SU;BYDAY=TU,TH ==> (1997 9:00 AM EDT)September 2,4,9,11,16,18,23,25,30;October 2 Every other week on Monday, Wednesday and Friday until December 24, 1997, but starting on Tuesday, September 2, 1997: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;UNTIL=19971224T000000Z;WKST=SU; BYDAY=MO,WE,FR ==> (1997 9:00 AM EDT)September 2,3,5,15,17,19,29;October 1,3,13,15,17 (1997 9:00 AM EST)October 27,29,31;November 10,12,14,24,26,28; December 8,10,12,22 Every other week on Tuesday and Thursday, for 8 occurrences: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=8;WKST=SU;BYDAY=TU,TH ==> (1997 9:00 AM EDT)September 2,4,16,18,30;October 2,14,16 Monthly on the 1st Friday for ten occurrences: DTSTART;TZID=US-Eastern:19970905T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR ==> (1997 9:00 AM EDT)September 5;October 3 (1997 9:00 AM EST)November 7;Dec 5 (1998 9:00 AM EST)January 2;February 6;March 6;April 3 (1998 9:00 AM EDT)May 1;June 5 Monthly on the 1st Friday until December 24, 1997: DTSTART;TZID=US-Eastern:19970905T090000 RRULE:FREQ=MONTHLY;UNTIL=19971224T000000Z;BYDAY=1FR ==> (1997 9:00 AM EDT)September 5;October 3 (1997 9:00 AM EST)November 7;December 5 Every other month on the 1st and last Sunday of the month for 10 occurrences: DTSTART;TZID=US-Eastern:19970907T090000 RRULE:FREQ=MONTHLY;INTERVAL=2;COUNT=10;BYDAY=1SU,-1SU ==> (1997 9:00 AM EDT)September 7,28 (1997 9:00 AM EST)November 2,30 Dawson & Stenerson Standards Track [Page 120] RFC 2445 iCalendar November 1998 (1998 9:00 AM EST)January 4,25;March 1,29 (1998 9:00 AM EDT)May 3,31 Monthly on the second to last Monday of the month for 6 months: DTSTART;TZID=US-Eastern:19970922T090000 RRULE:FREQ=MONTHLY;COUNT=6;BYDAY=-2MO ==> (1997 9:00 AM EDT)September 22;October 20 (1997 9:00 AM EST)November 17;December 22 (1998 9:00 AM EST)January 19;February 16 Monthly on the third to the last day of the month, forever: DTSTART;TZID=US-Eastern:19970928T090000 RRULE:FREQ=MONTHLY;BYMONTHDAY=-3 ==> (1997 9:00 AM EDT)September 28 (1997 9:00 AM EST)October 29;November 28;December 29 (1998 9:00 AM EST)January 29;February 26 ... Monthly on the 2nd and 15th of the month for 10 occurrences: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=2,15 ==> (1997 9:00 AM EDT)September 2,15;October 2,15 (1997 9:00 AM EST)November 2,15;December 2,15 (1998 9:00 AM EST)January 2,15 Monthly on the first and last day of the month for 10 occurrences: DTSTART;TZID=US-Eastern:19970930T090000 RRULE:FREQ=MONTHLY;COUNT=10;BYMONTHDAY=1,-1 ==> (1997 9:00 AM EDT)September 30;October 1 (1997 9:00 AM EST)October 31;November 1,30;December 1,31 (1998 9:00 AM EST)January 1,31;February 1 Every 18 months on the 10th thru 15th of the month for 10 occurrences: DTSTART;TZID=US-Eastern:19970910T090000 RRULE:FREQ=MONTHLY;INTERVAL=18;COUNT=10;BYMONTHDAY=10,11,12,13,14, 15 ==> (1997 9:00 AM EDT)September 10,11,12,13,14,15 Dawson & Stenerson Standards Track [Page 121] RFC 2445 iCalendar November 1998 (1999 9:00 AM EST)March 10,11,12,13 Every Tuesday, every other month: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=MONTHLY;INTERVAL=2;BYDAY=TU ==> (1997 9:00 AM EDT)September 2,9,16,23,30 (1997 9:00 AM EST)November 4,11,18,25 (1998 9:00 AM EST)January 6,13,20,27;March 3,10,17,24,31 ... Yearly in June and July for 10 occurrences: DTSTART;TZID=US-Eastern:19970610T090000 RRULE:FREQ=YEARLY;COUNT=10;BYMONTH=6,7 ==> (1997 9:00 AM EDT)June 10;July 10 (1998 9:00 AM EDT)June 10;July 10 (1999 9:00 AM EDT)June 10;July 10 (2000 9:00 AM EDT)June 10;July 10 (2001 9:00 AM EDT)June 10;July 10 Note: Since none of the BYDAY, BYMONTHDAY or BYYEARDAY components are specified, the day is gotten from DTSTART Every other year on January, February, and March for 10 occurrences: DTSTART;TZID=US-Eastern:19970310T090000 RRULE:FREQ=YEARLY;INTERVAL=2;COUNT=10;BYMONTH=1,2,3 ==> (1997 9:00 AM EST)March 10 (1999 9:00 AM EST)January 10;February 10;March 10 (2001 9:00 AM EST)January 10;February 10;March 10 (2003 9:00 AM EST)January 10;February 10;March 10 Every 3rd year on the 1st, 100th and 200th day for 10 occurrences: DTSTART;TZID=US-Eastern:19970101T090000 RRULE:FREQ=YEARLY;INTERVAL=3;COUNT=10;BYYEARDAY=1,100,200 ==> (1997 9:00 AM EST)January 1 (1997 9:00 AM EDT)April 10;July 19 (2000 9:00 AM EST)January 1 (2000 9:00 AM EDT)April 9;July 18 (2003 9:00 AM EST)January 1 (2003 9:00 AM EDT)April 10;July 19 (2006 9:00 AM EST)January 1 Every 20th Monday of the year, forever: Dawson & Stenerson Standards Track [Page 122] RFC 2445 iCalendar November 1998 DTSTART;TZID=US-Eastern:19970519T090000 RRULE:FREQ=YEARLY;BYDAY=20MO ==> (1997 9:00 AM EDT)May 19 (1998 9:00 AM EDT)May 18 (1999 9:00 AM EDT)May 17 ... Monday of week number 20 (where the default start of the week is Monday), forever: DTSTART;TZID=US-Eastern:19970512T090000 RRULE:FREQ=YEARLY;BYWEEKNO=20;BYDAY=MO ==> (1997 9:00 AM EDT)May 12 (1998 9:00 AM EDT)May 11 (1999 9:00 AM EDT)May 17 ... Every Thursday in March, forever: DTSTART;TZID=US-Eastern:19970313T090000 RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=TH ==> (1997 9:00 AM EST)March 13,20,27 (1998 9:00 AM EST)March 5,12,19,26 (1999 9:00 AM EST)March 4,11,18,25 ... Every Thursday, but only during June, July, and August, forever: DTSTART;TZID=US-Eastern:19970605T090000 RRULE:FREQ=YEARLY;BYDAY=TH;BYMONTH=6,7,8 ==> (1997 9:00 AM EDT)June 5,12,19,26;July 3,10,17,24,31; August 7,14,21,28 (1998 9:00 AM EDT)June 4,11,18,25;July 2,9,16,23,30; August 6,13,20,27 (1999 9:00 AM EDT)June 3,10,17,24;July 1,8,15,22,29; August 5,12,19,26 ... Every Friday the 13th, forever: DTSTART;TZID=US-Eastern:19970902T090000 EXDATE;TZID=US-Eastern:19970902T090000 RRULE:FREQ=MONTHLY;BYDAY=FR;BYMONTHDAY=13 Dawson & Stenerson Standards Track [Page 123] RFC 2445 iCalendar November 1998 ==> (1998 9:00 AM EST)February 13;March 13;November 13 (1999 9:00 AM EDT)August 13 (2000 9:00 AM EDT)October 13 ... The first Saturday that follows the first Sunday of the month, forever: DTSTART;TZID=US-Eastern:19970913T090000 RRULE:FREQ=MONTHLY;BYDAY=SA;BYMONTHDAY=7,8,9,10,11,12,13 ==> (1997 9:00 AM EDT)September 13;October 11 (1997 9:00 AM EST)November 8;December 13 (1998 9:00 AM EST)January 10;February 7;March 7 (1998 9:00 AM EDT)April 11;May 9;June 13... ... Every four years, the first Tuesday after a Monday in November, forever (U.S. Presidential Election day): DTSTART;TZID=US-Eastern:19961105T090000 RRULE:FREQ=YEARLY;INTERVAL=4;BYMONTH=11;BYDAY=TU;BYMONTHDAY=2,3,4, 5,6,7,8 ==> (1996 9:00 AM EST)November 5 (2000 9:00 AM EST)November 7 (2004 9:00 AM EST)November 2 ... The 3rd instance into the month of one of Tuesday, Wednesday or Thursday, for the next 3 months: DTSTART;TZID=US-Eastern:19970904T090000 RRULE:FREQ=MONTHLY;COUNT=3;BYDAY=TU,WE,TH;BYSETPOS=3 ==> (1997 9:00 AM EDT)September 4;October 7 (1997 9:00 AM EST)November 6 The 2nd to last weekday of the month: DTSTART;TZID=US-Eastern:19970929T090000 RRULE:FREQ=MONTHLY;BYDAY=MO,TU,WE,TH,FR;BYSETPOS=-2 ==> (1997 9:00 AM EDT)September 29 (1997 9:00 AM EST)October 30;November 27;December 30 (1998 9:00 AM EST)January 29;February 26;March 30 ... Dawson & Stenerson Standards Track [Page 124] RFC 2445 iCalendar November 1998 Every 3 hours from 9:00 AM to 5:00 PM on a specific day: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=HOURLY;INTERVAL=3;UNTIL=19970902T170000Z ==> (September 2, 1997 EDT)09:00,12:00,15:00 Every 15 minutes for 6 occurrences: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=MINUTELY;INTERVAL=15;COUNT=6 ==> (September 2, 1997 EDT)09:00,09:15,09:30,09:45,10:00,10:15 Every hour and a half for 4 occurrences: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=MINUTELY;INTERVAL=90;COUNT=4 ==> (September 2, 1997 EDT)09:00,10:30;12:00;13:30 Every 20 minutes from 9:00 AM to 4:40 PM every day: DTSTART;TZID=US-Eastern:19970902T090000 RRULE:FREQ=DAILY;BYHOUR=9,10,11,12,13,14,15,16;BYMINUTE=0,20,40 or RRULE:FREQ=MINUTELY;INTERVAL=20;BYHOUR=9,10,11,12,13,14,15,16 ==> (September 2, 1997 EDT)9:00,9:20,9:40,10:00,10:20, ... 16:00,16:20,16:40 (September 3, 1997 EDT)9:00,9:20,9:40,10:00,10:20, ...16:00,16:20,16:40 ... An example where the days generated makes a difference because of WKST: DTSTART;TZID=US-Eastern:19970805T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=MO ==> (1997 EDT)Aug 5,10,19,24 changing only WKST from MO to SU, yields different results... DTSTART;TZID=US-Eastern:19970805T090000 RRULE:FREQ=WEEKLY;INTERVAL=2;COUNT=4;BYDAY=TU,SU;WKST=SU ==> (1997 EDT)August 5,17,19,31 Dawson & Stenerson Standards Track [Page 125] RFC 2445 iCalendar November 1998 4.8.6 Alarm Component Properties The following properties specify alarm information in calendar components. 4.8.6.1 Action Property Name: ACTION Purpose: This property defines the action to be invoked when an alarm is triggered. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST be specified once in a "VALARM" calendar component. Description: Each "VALARM" calendar component has a particular type of action associated with it. This property specifies the type of action Format Definition: The property is defined by the following notation: action = "ACTION" actionparam ":" actionvalue CRLF actionparam = *(";" xparam) actionvalue = "AUDIO" / "DISPLAY" / "EMAIL" / "PROCEDURE" / iana-token / x-name Example: The following are examples of this property in a "VALARM" calendar component: ACTION:AUDIO ACTION:DISPLAY ACTION:PROCEDURE 4.8.6.2 Repeat Count Property Name: REPEAT Purpose: This property defines the number of time the alarm should be repeated, after the initial trigger. Dawson & Stenerson Standards Track [Page 126] RFC 2445 iCalendar November 1998 Value Type: INTEGER Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in a "VALARM" calendar component. Description: If the alarm triggers more than once, then this property MUST be specified along with the "DURATION" property. Format Definition: The property is defined by the following notation: repeatcnt = "REPEAT" repparam ":" integer CRLF ;Default is "0", zero. repparam = *(";" xparam) Example: The following is an example of this property for an alarm that repeats 4 additional times with a 5 minute delay after the initial triggering of the alarm: REPEAT:4 DURATION:PT5M 4.8.6.3 Trigger Property Name: TRIGGER Purpose: This property specifies when an alarm will trigger. Value Type: The default value type is DURATION. The value type can be set to a DATE-TIME value type, in which case the value MUST specify a UTC formatted DATE-TIME value. Property Parameters: Non-standard, value data type, time zone identifier or trigger relationship property parameters can be specified on this property. The trigger relationship property parameter MUST only be specified when the value type is DURATION. Conformance: This property MUST be specified in the "VALARM" calendar component. Description: Within the "VALARM" calendar component, this property defines when the alarm will trigger. The default value type is DURATION, specifying a relative time for the trigger of the alarm. The default duration is relative to the start of an event or to-do that the alarm is associated with. The duration can be explicitly set Dawson & Stenerson Standards Track [Page 127] RFC 2445 iCalendar November 1998 to trigger from either the end or the start of the associated event or to-do with the "RELATED" parameter. A value of START will set the alarm to trigger off the start of the associated event or to-do. A value of END will set the alarm to trigger off the end of the associated event or to-do. Either a positive or negative duration may be specified for the "TRIGGER" property. An alarm with a positive duration is triggered after the associated start or end of the event or to-do. An alarm with a negative duration is triggered before the associated start or end of the event or to-do. The "RELATED" property parameter is not valid if the value type of the property is set to DATE-TIME (i.e., for an absolute date and time alarm trigger). If a value type of DATE-TIME is specified, then the property value MUST be specified in the UTC time format. If an absolute trigger is specified on an alarm for a recurring event or to-do, then the alarm will only trigger for the specified absolute date/time, along with any specified repeating instances. If the trigger is set relative to START, then the "DTSTART" property MUST be present in the associated "VEVENT" or "VTODO" calendar component. If an alarm is specified for an event with the trigger set relative to the END, then the "DTEND" property or the "DSTART" and "DURATION' properties MUST be present in the associated "VEVENT" calendar component. If the alarm is specified for a to-do with a trigger set relative to the END, then either the "DUE" property or the "DSTART" and "DURATION' properties MUST be present in the associated "VTODO" calendar component. Alarms specified in an event or to-do which is defined in terms of a DATE value type will be triggered relative to 00:00:00 UTC on the specified date. For example, if "DTSTART:19980205, then the duration trigger will be relative to19980205T000000Z. Format Definition: The property is defined by the following notation: trigger = "TRIGGER" (trigrel / trigabs) trigrel = *( ; the following are optional, ; but MUST NOT occur more than once (";" "VALUE" "=" "DURATION") / (";" trigrelparam) / ; the following is optional, Dawson & Stenerson Standards Track [Page 128] RFC 2445 iCalendar November 1998 ; and MAY occur more than once (";" xparam) ) ":" dur-value trigabs = 1*( ; the following is REQUIRED, ; but MUST NOT occur more than once (";" "VALUE" "=" "DATE-TIME") / ; the following is optional, ; and MAY occur more than once (";" xparam) ) ":" date-time Example: A trigger set 15 minutes prior to the start of the event or to-do. TRIGGER:-P15M A trigger set 5 minutes after the end of the event or to-do. TRIGGER;RELATED=END:P5M A trigger set to an absolute date/time. TRIGGER;VALUE=DATE-TIME:19980101T050000Z 4.8.7 Change Management Component Properties The following properties specify change management information in calendar components. 4.8.7.1 Date/Time Created Property Name: CREATED Purpose: This property specifies the date and time that the calendar information was created by the calendar user agent in the calendar store. Note: This is analogous to the creation date and time for a file in the file system. Dawson & Stenerson Standards Track [Page 129] RFC 2445 iCalendar November 1998 Value Type: DATE-TIME Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property can be specified once in "VEVENT", "VTODO" or "VJOURNAL" calendar components. Description: The date and time is a UTC value. Format Definition: The property is defined by the following notation: created = "CREATED" creaparam ":" date-time CRLF creaparam = *(";" xparam) Example: The following is an example of this property: CREATED:19960329T133000Z 4.8.7.2 Date/Time Stamp Property Name: DTSTAMP Purpose: The property indicates the date/time that the instance of the iCalendar object was created. Value Type: DATE-TIME Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property MUST be included in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. Description: The value MUST be specified in the UTC time format. This property is also useful to protocols such as [IMIP] that have inherent latency issues with the delivery of content. This property will assist in the proper sequencing of messages containing iCalendar objects. This property is different than the "CREATED" and "LAST-MODIFIED" properties. These two properties are used to specify when the particular calendar data in the calendar store was created and last modified. This is different than when the iCalendar object representation of the calendar service information was created or last modified. Dawson & Stenerson Standards Track [Page 130] RFC 2445 iCalendar November 1998 Format Definition: The property is defined by the following notation: dtstamp = "DTSTAMP" stmparam ":" date-time CRLF stmparam = *(";" xparam) Example: DTSTAMP:19971210T080000Z 4.8.7.3 Last Modified Property Name: LAST-MODIFIED Purpose: The property specifies the date and time that the information associated with the calendar component was last revised in the calendar store. Note: This is analogous to the modification date and time for a file in the file system. Value Type: DATE-TIME Property Parameters: Non-standard property parameters can be specified on this property. Conformance: This property can be specified in the "EVENT", "VTODO", "VJOURNAL" or "VTIMEZONE" calendar components. Description: The property value MUST be specified in the UTC time format. Format Definition: The property is defined by the following notation: last-mod = "LAST-MODIFIED" lstparam ":" date-time CRLF lstparam = *(";" xparam) Example: The following is are examples of this property: LAST-MODIFIED:19960817T133000Z 4.8.7.4 Sequence Number Property Name: SEQUENCE Purpose: This property defines the revision sequence number of the calendar component within a sequence of revisions. Dawson & Stenerson Standards Track [Page 131] RFC 2445 iCalendar November 1998 Value Type: integer Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property can be specified in "VEVENT", "VTODO" or "VJOURNAL" calendar component. Description: When a calendar component is created, its sequence number is zero (US-ASCII decimal 48). It is monotonically incremented by the "Organizer's" CUA each time the "Organizer" makes a significant revision to the calendar component. When the "Organizer" makes changes to one of the following properties, the sequence number MUST be incremented: . "DTSTART" . "DTEND" . "DUE" . "RDATE" . "RRULE" . "EXDATE" . "EXRULE" . "STATUS" In addition, changes made by the "Organizer" to other properties can also force the sequence number to be incremented. The "Organizer" CUA MUST increment the sequence number when ever it makes changes to properties in the calendar component that the "Organizer" deems will jeopardize the validity of the participation status of the "Attendees". For example, changing the location of a meeting from one locale to another distant locale could effectively impact the participation status of the "Attendees". The "Organizer" includes this property in an iCalendar object that it sends to an "Attendee" to specify the current version of the calendar component. The "Attendee" includes this property in an iCalendar object that it sends to the "Organizer" to specify the version of the calendar component that the "Attendee" is referring to. Dawson & Stenerson Standards Track [Page 132] RFC 2445 iCalendar November 1998 A change to the sequence number is not the mechanism that an "Organizer" uses to request a response from the "Attendees". The "RSVP" parameter on the "ATTENDEE" property is used by the "Organizer" to indicate that a response from the "Attendees" is requested. Format Definition: This property is defined by the following notation: seq = "SEQUENCE" seqparam ":" integer CRLF ; Default is "0" seqparam = *(";" xparam) Example: The following is an example of this property for a calendar component that was just created by the "Organizer". SEQUENCE:0 The following is an example of this property for a calendar component that has been revised two different times by the "Organizer". SEQUENCE:2 4.8.8 Miscellaneous Component Properties The following properties specify information about a number of miscellaneous features of calendar components. 4.8.8.1 Non-standard Properties Property Name: Any property name with a "X-" prefix Purpose: This class of property provides a framework for defining non-standard properties. Value Type: TEXT Property Parameters: Non-standard and language property parameters can be specified on this property. Conformance: This property can be specified in any calendar component. Description: The MIME Calendaring and Scheduling Content Type provides a "standard mechanism for doing non-standard things". This extension support is provided for implementers to "push the envelope" on the existing version of the memo. Extension properties are Dawson & Stenerson Standards Track [Page 133] RFC 2445 iCalendar November 1998 specified by property and/or property parameter names that have the prefix text of "X-" (the two character sequence: LATIN CAPITAL LETTER X character followed by the HYPEN-MINUS character). It is recommended that vendors concatenate onto this sentinel another short prefix text to identify the vendor. This will facilitate readability of the extensions and minimize possible collision of names between different vendors. User agents that support this content type are expected to be able to parse the extension properties and property parameters but can ignore them. At present, there is no registration authority for names of extension properties and property parameters. The data type for this property is TEXT. Optionally, the data type can be any of the other valid data types. Format Definition: The property is defined by the following notation: x-prop = x-name *(";" xparam) [";" languageparam] ":" text CRLF ; Lines longer than 75 octets should be folded Example: The following might be the ABC vendor's extension for an audio-clip form of subject property: X-ABC-MMSUBJ;X-ABC-MMSUBJTYPE=wave:http://load.noise.org/mysubj.wav 4.8.8.2 Request Status Property Name: REQUEST-STATUS Purpose: This property defines the status code returned for a scheduling request. Value Type: TEXT Property Parameters: Non-standard and language property parameters can be specified on this property. Conformance: The property can be specified in "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar component. Description: This property is used to return status code information related to the processing of an associated iCalendar object. The data type for this property is TEXT. The value consists of a short return status component, a longer return status description component, and optionally a status-specific data component. The components of the value are separated by the SEMICOLON character (US-ASCII decimal 59). Dawson & Stenerson Standards Track [Page 134] RFC 2445 iCalendar November 1998 The short return status is a PERIOD character (US-ASCII decimal 46) separated 3-tuple of integers. For example, "3.1.1". The successive levels of integers provide for a successive level of status code granularity. The following are initial classes for the return status code. Individual iCalendar object methods will define specific return status codes for these classes. In addition, other classes for the return status code may be defined using the registration process defined later in this memo. |==============+===============================================| | Short Return | Longer Return Status Description | | Status Code | | |==============+===============================================| | 1.xx | Preliminary success. This class of status | | | of status code indicates that the request has | | | request has been initially processed but that | | | completion is pending. | |==============+===============================================| | 2.xx | Successful. This class of status code | | | indicates that the request was completed | | | successfuly. However, the exact status code | | | can indicate that a fallback has been taken. | |==============+===============================================| | 3.xx | Client Error. This class of status code | | | indicates that the request was not successful.| | | The error is the result of either a syntax or | | | a semantic error in the client formatted | | | request. Request should not be retried until | | | the condition in the request is corrected. | |==============+===============================================| | 4.xx | Scheduling Error. This class of status code | | | indicates that the request was not successful.| | | Some sort of error occurred within the | | | calendaring and scheduling service, not | | | directly related to the request itself. | |==============+===============================================| Format Definition: The property is defined by the following notation: rstatus = "REQUEST-STATUS" rstatparam ":" statcode ";" statdesc [";" extdata] rstatparam = *( ; the following is optional, ; but MUST NOT occur more than once Dawson & Stenerson Standards Track [Page 135] RFC 2445 iCalendar November 1998 (";" languageparm) / ; the following is optional, ; and MAY occur more than once (";" xparam) ) statcode = 1*DIGIT *("." 1*DIGIT) ;Hierarchical, numeric return status code statdesc = text ;Textual status description extdata = text ;Textual exception data. For example, the offending property ;name and value or complete property line. Example: The following are some possible examples of this property. The COMMA and SEMICOLON separator characters in the property value are BACKSLASH character escaped because they appear in a text value. REQUEST-STATUS:2.0;Success REQUEST-STATUS:3.1;Invalid property value;DTSTART:96-Apr-01 REQUEST-STATUS:2.8; Success\, repeating event ignored. Scheduled as a single event.;RRULE:FREQ=WEEKLY\;INTERVAL=2 REQUEST-STATUS:4.1;Event conflict. Date/time is busy. REQUEST-STATUS:3.7;Invalid calendar user;ATTENDEE: MAILTO:jsmith@host.com 5 iCalendar Object Examples The following examples are provided as an informational source of illustrative iCalendar objects consistent with this content type. The following example specifies a three-day conference that begins at 8:00 AM EDT, September 18, 1996 and end at 6:00 PM EDT, September 20, 1996. BEGIN:VCALENDAR PRODID:-//xyz Corp//NONSGML PDA Calendar Verson 1.0//EN VERSION:2.0 BEGIN:VEVENT DTSTAMP:19960704T120000Z UID:uid1@host.com ORGANIZER:MAILTO:jsmith@host.com DTSTART:19960918T143000Z DTEND:19960920T220000Z STATUS:CONFIRMED Dawson & Stenerson Standards Track [Page 136] RFC 2445 iCalendar November 1998 CATEGORIES:CONFERENCE SUMMARY:Networld+Interop Conference DESCRIPTION:Networld+Interop Conference and Exhibit\nAtlanta World Congress Center\n Atlanta\, Georgia END:VEVENT END:VCALENDAR The following example specifies a group scheduled meeting that begin at 8:30 AM EST on March 12, 1998 and end at 9:30 AM EST on March 12, 1998. The "Organizer" has scheduled the meeting with one or more calendar users in a group. A time zone specification for Eastern United States has been specified. BEGIN:VCALENDAR PRODID:-//RDU Software//NONSGML HandCal//EN VERSION:2.0 BEGIN:VTIMEZONE TZID:US-Eastern BEGIN:STANDARD DTSTART:19981025T020000 RDATE:19981025T020000 TZOFFSETFROM:-0400 TZOFFSETTO:-0500 TZNAME:EST END:STANDARD BEGIN:DAYLIGHT DTSTART:19990404T020000 RDATE:19990404T020000 TZOFFSETFROM:-0500 TZOFFSETTO:-0400 TZNAME:EDT END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT DTSTAMP:19980309T231000Z UID:guid-1.host1.com ORGANIZER;ROLE=CHAIR:MAILTO:mrbig@host.com ATTENDEE;RSVP=TRUE;ROLE=REQ-PARTICIPANT;CUTYPE=GROUP: MAILTO:employee-A@host.com DESCRIPTION:Project XYZ Review Meeting CATEGORIES:MEETING CLASS:PUBLIC CREATED:19980309T130000Z SUMMARY:XYZ Project Review DTSTART;TZID=US-Eastern:19980312T083000 DTEND;TZID=US-Eastern:19980312T093000 LOCATION:1CP Conference Room 4350 END:VEVENT END:VCALENDAR Dawson & Stenerson Standards Track [Page 137] RFC 2445 iCalendar November 1998 The following is an example of an iCalendar object passed in a MIME message with a single body part consisting of a "text/calendar" Content Type. TO:jsmith@host1.com FROM:jdoe@host1.com MIME-VERSION:1.0 MESSAGE-ID: CONTENT-TYPE:text/calendar BEGIN:VCALENDAR METHOD:xyz VERSION:2.0 PRODID:-//ABC Corporation//NONSGML My Product//EN BEGIN:VEVENT DTSTAMP:19970324T1200Z SEQUENCE:0 UID:uid3@host1.com ORGANIZER:MAILTO:jdoe@host1.com ATTENDEE;RSVP=TRUE:MAILTO:jsmith@host1.com DTSTART:19970324T123000Z DTEND:19970324T210000Z CATEGORIES:MEETING,PROJECT CLASS:PUBLIC SUMMARY:Calendaring Interoperability Planning Meeting DESCRIPTION:Discuss how we can test c&s interoperability\n using iCalendar and other IETF standards. LOCATION:LDB Lobby ATTACH;FMTTYPE=application/postscript:ftp://xyzCorp.com/pub/ conf/bkgrnd.ps END:VEVENT END:VCALENDAR The following is an example of a to-do due on April 15, 1998. An audio alarm has been specified to remind the calendar user at noon, the day before the to-do is expected to be completed and repeat hourly, four additional times. The to-do definition has been modified twice since it was initially created. BEGIN:VCALENDAR VERSION:2.0 PRODID:-//ABC Corporation//NONSGML My Product//EN BEGIN:VTODO DTSTAMP:19980130T134500Z SEQUENCE:2 UID:uid4@host1.com ORGANIZER:MAILTO:unclesam@us.gov ATTENDEE;PARTSTAT=ACCEPTED:MAILTO:jqpublic@host.com Dawson & Stenerson Standards Track [Page 138] RFC 2445 iCalendar November 1998 DUE:19980415T235959 STATUS:NEEDS-ACTION SUMMARY:Submit Income Taxes BEGIN:VALARM ACTION:AUDIO TRIGGER:19980403T120000 ATTACH;FMTTYPE=audio/basic:http://host.com/pub/audio- files/ssbanner.aud REPEAT:4 DURATION:PT1H END:VALARM END:VTODO END:VCALENDAR The following is an example of a journal entry. BEGIN:VCALENDAR VERSION:2.0 PRODID:-//ABC Corporation//NONSGML My Product//EN BEGIN:VJOURNAL DTSTAMP:19970324T120000Z UID:uid5@host1.com ORGANIZER:MAILTO:jsmith@host.com STATUS:DRAFT CLASS:PUBLIC CATEGORIES:Project Report,XYZ,Weekly Meeting DESCRIPTION:Project xyz Review Meeting Minutes\n Agenda\n1. Review of project version 1.0 requirements.\n2. Definition of project processes.\n3. Review of project schedule.\n Participants: John Smith\, Jane Doe\, Jim Dandy\n-It was decided that the requirements need to be signed off by product marketing.\n-Project processes were accepted.\n -Project schedule needs to account for scheduled holidays and employee vacation time. Check with HR for specific dates.\n-New schedule will be distributed by Friday.\n- Next weeks meeting is cancelled. No meeting until 3/23. END:VJOURNAL END:VCALENDAR The following is an example of published busy time information. The iCalendar object might be placed in the network resource www.host.com/calendar/busytime/jsmith.ifb. BEGIN:VCALENDAR VERSION:2.0 PRODID:-//RDU Software//NONSGML HandCal//EN BEGIN:VFREEBUSY Dawson & Stenerson Standards Track [Page 139] RFC 2445 iCalendar November 1998 ORGANIZER:MAILTO:jsmith@host.com DTSTART:19980313T141711Z DTEND:19980410T141711Z FREEBUSY:19980314T233000Z/19980315T003000Z FREEBUSY:19980316T153000Z/19980316T163000Z FREEBUSY:19980318T030000Z/19980318T040000Z URL:http://www.host.com/calendar/busytime/jsmith.ifb END:VFREEBUSY END:VCALENDAR 6 Recommended Practices These recommended practices should be followed in order to assure consistent handling of the following cases for an iCalendar object. 1. Content lines longer than 75 octets SHOULD be folded. 2. A calendar entry with a "DTSTART" property but no "DTEND" property does not take up any time. It is intended to represent an event that is associated with a given calendar date and time of day, such as an anniversary. Since the event does not take up any time, it MUST NOT be used to record busy time no matter what the value for the "TRANSP" property. 3. When the "DTSTART" and "DTEND", for "VEVENT", "VJOURNAL" and "VFREEBUSY" calendar components, and "DTSTART" and "DUE", for "VTODO" calendar components, have the same value data type (e.g., DATE-TIME), they SHOULD specify values in the same time format (e.g., UTC time format). 4. When the combination of the "RRULE" and "RDATE" properties on an iCalendar object produces multiple instances having the same start date/time, they should be collapsed to, and considered as, a single instance. 5. When a calendar user receives multiple requests for the same calendar component (e.g., REQUEST for a "VEVENT" calendar component) as a result of being on multiple mailing lists specified by "ATTENDEE" properties in the request, they SHOULD respond to only one of the requests. The calendar user SHOULD also specify (using the "MEMBER" parameter of the "ATTENDEE" property) which mailing list they are a member of. 6. An implementation can truncate a "SUMMARY" property value to 255 characters. Dawson & Stenerson Standards Track [Page 140] RFC 2445 iCalendar November 1998 7. If seconds of the minute are not supported by an implementation, then a value of "00" SHOULD be specified for the seconds component in a time value. 8. If the value type parameter (VALUE=) contains an unknown value type, it SHOULD be treated as TEXT. 9. TZURL values SHOULD NOT be specified as a FILE URI type. This URI form can be useful within an organization, but is problematic in the Internet. 10. Some possible English values for CATEGORIES property include "ANNIVERSARY", "APPOINTMENT", "BUSINESS", "EDUCATION", "HOLIDAY", "MEETING", "MISCELLANEOUS", "NON-WORKING HOURS", "NOT IN OFFICE", "PERSONAL", "PHONE CALL", "SICK DAY", "SPECIAL OCCASION", "TRAVEL", "VACATION". Categories can be specified in any registered language. 11. Some possible English values for RESOURCES property include "CATERING", "CHAIRS", "COMPUTER PROJECTOR", "EASEL", "OVERHEAD PROJECTOR", "SPEAKER PHONE", "TABLE", "TV", "VCR", "VIDEO PHONE", "VEHICLE". Resources can be specified in any registered language. 7 Registration of Content Type Elements This section provides the process for registration of MIME Calendaring and Scheduling Content Type iCalendar object methods and new or modified properties. 7.1 Registration of New and Modified iCalendar Object Methods New MIME Calendaring and Scheduling Content Type iCalendar object methods are registered by the publication of an IETF Request for Comments (RFC). Changes to an iCalendar object method are registered by the publication of a revision of the RFC defining the method. 7.2 Registration of New Properties This section defines procedures by which new properties or enumerated property values for the MIME Calendaring and Scheduling Content Type can be registered with the IANA. Non-IANA properties can be used by bilateral agreement, provided the associated properties names follow the "X-" convention. The procedures defined here are designed to allow public comment and review of new properties, while posing only a small impediment to the definition of new properties. Dawson & Stenerson Standards Track [Page 141] RFC 2445 iCalendar November 1998 Registration of a new property is accomplished by the following steps. 7.2.1 Define the property A property is defined by completing the following template. To: ietf-calendar@imc.org Subject: Registration of text/calendar MIME property XXX Property name: Property purpose: Property value type(s): Property parameter (s): Conformance: Description: Format definition: Examples: The meaning of each field in the template is as follows. Property name: The name of the property, as it will appear in the body of an text/calendar MIME Content-Type "property: value" line to the left of the colon ":". Property purpose: The purpose of the property (e.g., to indicate a delegate for the event or to-do, etc.). Give a short but clear description. Property value type (s): Any of the valid value types for the property value needs to be specified. The default value type also needs to be specified. If a new value type is specified, it needs to be declared in this section. Property parameter (s): Any of the valid property parameters for the property needs to be specified. Conformance: The calendar components that the property can appear in needs to be specified. Dawson & Stenerson Standards Track [Page 142] RFC 2445 iCalendar November 1998 Description: Any special notes about the property, how it is to be used, etc. Format definition: The ABNF for the property definition needs to be specified. Examples: One or more examples of instances of the property needs to be specified. 7.2.2 Post the Property definition The property description MUST be posted to the new property discussion list, ietf-calendar@imc.org. 7.2.3 Allow a comment period Discussion on the new property MUST be allowed to take place on the list for a minimum of two weeks. Consensus MUST be reached on the property before proceeding to the next step. 7.2.4 Submit the property for approval Once the two-week comment period has elapsed, and the proposer is convinced consensus has been reached on the property, the registration application should be submitted to the Method Reviewer for approval. The Method Reviewer is appointed to the Application Area Directors and can either accept or reject the property registration. An accepted registration should be passed on by the Method Reviewer to the IANA for inclusion in the official IANA method registry. The registration can be rejected for any of the following reasons. 1) Insufficient comment period; 2) Consensus not reached; 3) Technical deficiencies raised on the list or elsewhere have not been addressed. The Method Reviewer's decision to reject a property can be appealed by the proposer to the IESG, or the objections raised can be addressed by the proposer and the property resubmitted. 7.3 Property Change Control Existing properties can be changed using the same process by which they were registered. 1. Define the change 2. Post the change 3. Allow a comment period 4. Submit the property for approval Dawson & Stenerson Standards Track [Page 143] RFC 2445 iCalendar November 1998 Note that the original author or any other interested party can propose a change to an existing property, but that such changes should only be proposed when there are serious omissions or errors in the published memo. The Method Reviewer can object to a change if it is not backward compatible, but is not required to do so. Property definitions can never be deleted from the IANA registry, but properties which are no longer believed to be useful can be declared OBSOLETE by a change to their "intended use" field. 8 References [IMIP] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message-based Interoperability Protocol (IMIP)", RFC 2447, November 1998. [ITIP] Silverberg, S., Mansour, S., Dawson, F. and R. Hopson, "iCalendar Transport-Independent Interoperability Protocol (iTIP) : Scheduling Events, Busy Time, To-dos and Journal Entries", RFC 2446, November 1998. [ISO 8601] ISO 8601, "Data elements and interchange formats- Information interchange--Representation of dates and times", International Organization for Standardization, June, 1988. [ISO 9070] ISO/IEC 9070, "Information Technology_SGML Support Facilities--Registration Procedures for Public Text Owner Identifiers", Second Edition, International Organization for Standardization, April 1991. [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", STD 11, RFC 822, August 1982. [RFC 1738] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [RFC 1766] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [RFC 2045] Freed, N. and N. Borenstein, " Multipurpose Internet Mail Extensions (MIME) - Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC 2046] Freed, N. and N. Borenstein, " Multipurpose Internet Mail Extensions (MIME) - Part Two: Media Types", RFC 2046, November 1996. Dawson & Stenerson Standards Track [Page 144] RFC 2445 iCalendar November 1998 [RFC 2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) - Part Four: Registration Procedures", RFC 2048, January 1997. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC 2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC 2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. [RFC 2425] Howes, T., Smith, M. and F. Dawson, "A MIME Content-Type for Directory Information", RFC 2425, September 1998. [RFC 2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998. [TZ] Olson, A.D., et al, Time zone code and data, ftp://elsie.nci.nih.gov/pub/, updated periodically. [VCAL] Internet Mail Consortium, "vCalendar - The Electronic Calendaring and Scheduling Exchange Format", http://www.imc.org/pdi/vcal-10.txt, September 18, 1996. 9 Acknowledgments A hearty thanks to the IETF Calendaring and Scheduling Working Group and also the following individuals who have participated in the drafting, review and discussion of this memo: Roland Alden, Harald T. Alvestrand, Eric Berman, Denis Bigorgne, John Binici, Bill Bliss, Philippe Boucher, Steve Carter, Andre Courtemanche, Dave Crocker, David Curley, Alec Dun, John Evans, Ross Finlayson, Randell Flint, Ned Freed, Patrik Faltstrom, Chuck Grandgent, Mark Handley, Steve Hanna, Paul B. Hill, Paul Hoffman, Ross Hopson, Mark Horton, Daryl Huff, Bruce Kahn, C. Harald Koch, Ryan Jansen, Don Lavange, Antoine Leca, Theodore Lorek, Steve Mansour, Skip Montanaro, Keith Moore, Cecil Murray, Chris Newman, John Noerenberg, Ralph Patterson, Pete Resnick, Keith Rhodes, Robert Ripberger, John Rose, Doug Royer, Andras Salamar, Ted Schuh, Vinod Seraphin, Derrick Shadel, Ken Shan, Andrew Shuman, Steve Silverberg, William P. Spencer, John Sun, Mark Towfiq, Yvonne Tso, Robert Visnov, James L. Weiner, Mike Weston, William Wyatt. Dawson & Stenerson Standards Track [Page 145] RFC 2445 iCalendar November 1998 10 Authors' and Chairs' Addresses The following address information is provided in a MIME-VCARD, Electronic Business Card, format. The authors of this memo are: BEGIN:VCARD VERSION:3.0 N:Dawson;Frank FN:Frank Dawson ORG:Lotus Development Corporation ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford Drive; Raleigh;NC;27613-3502;USA TEL;TYPE=WORK,MSG:+1-919-676-9515 TEL;TYPE=WORK,FAX:+1-919-676-9564 EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com EMAIL;TYPE=INTERNET:fdawson@earthlink.net URL:http://home.earthlink.net/~fdawson END:VCARD BEGIN:VCARD VERSION:3.0 N:Stenerson;Derik FN:Derik Stenerson ORG:Microsoft Corporation ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way; Redmond;WA;98052-6399;USA TEL;TYPE=WORK,MSG:+1-425-936-5522 TEL;TYPE=WORK,FAX:+1-425-936-7329 EMAIL;TYPE=INTERNET:deriks@Microsoft.com END:VCARD The iCalendar object is a result of the work of the Internet Engineering Task Force Calendaring and Scheduling Working Group. The chairmen of that working group are: BEGIN:VCARD VERSION:3.0 N:Ganguly;Anik FN:Anik Ganguly ORG: Open Text Inc. ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road; Livonia;MI;48152;USA TEL;TYPE=WORK,MSG:+1-734-542-5955 EMAIL;TYPE=INTERNET:ganguly@acm.org END:VCARD Dawson & Stenerson Standards Track [Page 146] RFC 2445 iCalendar November 1998 The co-chairman of that working group is: BEGIN:VCARD VERSION:3.0 N:Moskowitz;Robert FN:Robert Moskowitz EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com END:VCARD Dawson & Stenerson Standards Track [Page 147] RFC 2445 iCalendar November 1998 11. Full Copyright Statement Copyright (C) The Internet Society (1998). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Dawson & Stenerson Standards Track [Page 148]


Network Working Group                                     S. Silverberg
Request for Comments: 2446                                    Microsoft
Category: Standards Track                                    S. Mansour
                                                               Netscape
                                                              F. Dawson
                                                                  Lotus
                                                              R. Hopson
                                                        ON Technologies
                                                          November 1998

       iCalendar Transport-Independent Interoperability Protocol
                                 (iTIP)
        Scheduling Events, BusyTime, To-dos and Journal Entries

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document specifies how calendaring systems use iCalendar objects
   to interoperate with other calendar systems. It does so in a general
   way so as to allow multiple methods of communication between systems.
   Subsequent documents specify interoperable methods of communications
   between systems that use this protocol.

   The document outlines a model for calendar exchange that defines both
   static and dynamic event, to-do, journal and free/busy objects.
   Static objects are used to transmit information from one entity to
   another without the expectation of continuity or referential
   integrity with the original item. Dynamic objects are a superset of
   static objects and will gracefully degrade to their static
   counterparts for clients that only support static objects.

   This document specifies an Internet protocol based on the iCalendar
   object specification that provides scheduling interoperability
   between different calendar systems. The Internet protocol is called
   the "iCalendar Transport-Independent Interoperability Protocol
   (iTIP)".

Silverberg, et. al.         Standards Track                     [Page 1]

RFC 2446                          iTIP                     November 1998

   iTIP complements the iCalendar object specification by adding
   semantics for group scheduling methods commonly available in current
   calendar systems. These scheduling methods permit two or more
   calendar systems to perform transactions such as publish, schedule,
   reschedule, respond to scheduling requests, negotiation of changes or
   cancel iCalendar-based calendar components.

   iTIP is defined independent of the particular transport used to
   transmit the scheduling information. Companion memos to iTIP provide
   bindings of the interoperability protocol to a number of Internet
   protocols.

Table of Contents

   1 INTRODUCTION...................................................5
    1.1 FORMATTING CONVENTIONS .....................................5
    1.2 RELATED DOCUMENTS ..........................................6
    1.3 ITIP ROLES AND TRANSACTIONS ................................6
   2 INTEROPERABILITY MODELS........................................8
    2.1 APPLICATION PROTOCOL .......................................9
      2.1.1 Calendar Entry State ...................................9
      2.1.2 Delegation .............................................9
      2.1.3 Acting on Behalf of other Calendar Users ..............10
      2.1.4 Component Revisions ...................................10
      2.1.5 Message Sequencing ....................................11
   3 APPLICATION PROTOCOL ELEMENTS.................................12
    3.1 COMMON COMPONENT RESTRICTION TABLES .......................13
    3.2 METHODS FOR VEVENT CALENDAR COMPONENTS ....................14
      3.2.1 PUBLISH ...............................................15
      3.2.2 REQUEST ...............................................17
        3.2.2.1 Rescheduling an Event..............................19
        3.2.2.2 Updating or Reconfirmation of an Event.............19
        3.2.2.3 Delegating an Event to another CU..................19
        3.2.2.4 Changing the Organizer.............................20
        3.2.2.5 Sending on Behalf of the Organizer.................20
        3.2.2.6 Forwarding to An Uninvited CU......................20
        3.2.2.7 Updating Attendee Status...........................21
      3.2.3 REPLY .................................................21
      3.2.4 ADD ...................................................23
      3.2.5 CANCEL ................................................25
      3.2.6 REFRESH ...............................................26
      3.2.7 COUNTER ...............................................28
      3.2.8 DECLINECOUNTER ........................................29
    3.3 METHODS FOR VFREEBUSY COMPONENTS ..........................31
      3.3.1 PUBLISH ...............................................32
      3.3.2 REQUEST ...............................................33
      3.3.3 REPLY .................................................34
    3.4 METHODS FOR VTODO COMPONENTS ..............................35

Silverberg, et. al.         Standards Track                     [Page 2]

RFC 2446                          iTIP                     November 1998

      3.4.1 PUBLISH ...............................................35
      3.4.2 REQUEST ...............................................37
        3.4.2.1 REQUEST for Rescheduling a VTODO...................39
        3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO....39
        3.4.2.3 REQUEST for Delegating a VTODO.....................40
        3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User....40
        3.4.2.5 REQUEST Updated Attendee Status....................41
      3.4.3 REPLY .................................................41
      3.4.4 ADD ...................................................43
      3.4.5 CANCEL ................................................44
      3.4.6 REFRESH ...............................................46
      3.4.7 COUNTER ...............................................48
      3.4.8 DECLINECOUNTER ........................................49
    3.5 METHODS FOR VJOURNAL COMPONENTS ...........................50
      3.5.1 PUBLISH ...............................................51
      3.5.2 ADD ...................................................52
      3.5.3 CANCEL ................................................53
    3.6 STATUS REPLIES ............................................55
    3.7 IMPLEMENTATION CONSIDERATIONS .............................57
      3.7.1 Working With Recurrence Instances .....................57
      3.7.2 Attendee Property Considerations ......................58
      3.7.3 X-Tokens ..............................................59
   4 EXAMPLES......................................................59
    4.1 PUBLISHED EVENT EXAMPLES ..................................59
      4.1.1 A Minimal Published Event .............................60
      4.1.2 Changing A Published Event ............................60
      4.1.3 Canceling A Published Event ...........................61
      4.1.4 A Rich Published Event ................................62
      4.1.5 Anniversaries or Events attached to entire days .......63
    4.2 GROUP EVENT EXAMPLES ......................................63
      4.2.1 A Group Event Request .................................64
      4.2.2 Reply To A Group Event Request ........................65
      4.2.3 Update An Event .......................................65
      4.2.4 Countering an Event Proposal ..........................66
      4.2.5 Delegating an Event ...................................68
      4.2.6 Delegate Accepts the Meeting ..........................70
      4.2.7 Delegate Declines the Meeting .........................71
      4.2.8 Forwarding an Event Request ...........................72
      4.2.9 Cancel A Group Event ..................................72
      4.2.10 Removing Attendees ...................................74
      4.2.11 Replacing the Organizer ..............................75
    4.3 BUSY TIME EXAMPLES ........................................76
      4.3.1 Request Busy Time .....................................77
      4.3.2 Reply To A Busy Time Request ..........................77
    4.4 RECURRING EVENT AND TIME ZONE EXAMPLES ....................78
      4.4.1 A Recurring Event Spanning Time Zones .................78
      4.4.2 Modify A Recurring Instance ...........................79
      4.4.3 Cancel an Instance ....................................81

Silverberg, et. al.         Standards Track                     [Page 3]

RFC 2446                          iTIP                     November 1998

      4.4.4 Cancel Recurring Event ................................81
      4.4.5 Change All Future Instances ...........................82
      4.4.6 Add A New Instance To A Recurring Event ...............82
      4.4.7 Add A New Series of Instances To A Recurring Event ....83
      4.4.8 Counter An Instance Of A Recurring Event ..............87
      4.4.9 Error Reply To A Request ..............................88
    4.5 GROUP TO-DO EXAMPLES ......................................89
      4.5.1 A VTODO Request .......................................90
      4.5.2 A VTODO Reply .........................................90
      4.5.3 A VTODO Request for Updated Status ....................91
      4.5.4 A Reply: Percent-Complete .............................91
      4.5.5 A Reply: Completed ....................................92
      4.5.6 An Updated VTODO Request ..............................92
      4.5.7 Recurring VTODOs ......................................92
        4.5.7.1 Request for a Recurring VTODO......................93
        4.5.7.2 Calculating due dates in recurring VTODOs..........93
        4.5.7.3 Replying to an instance of a recurring VTODO.......93
    4.6 JOURNAL EXAMPLES ..........................................94
    4.7 OTHER EXAMPLES ............................................94
      4.7.1 Event Refresh .........................................94
      4.7.2 Bad RECURRENCE-ID .....................................95
   5 APPLICATION PROTOCOL FALLBACKS................................97
    5.1 PARTIAL IMPLEMENTATION ....................................97
      5.1.1 Event-Related Fallbacks ...............................97
      5.1.2 Free/Busy-Related Fallbacks ...........................99
      5.1.3 To-Do-Related Fallbacks ...............................99
      5.1.4 Journal-Related Fallbacks ............................101
    5.2 LATENCY ISSUES ...........................................102
      5.2.1 Cancellation of an Unknown Calendar Component. .......102
      5.2.2 Unexpected Reply from an Unknown Delegate ............103
    5.3 SEQUENCE NUMBER ..........................................103
   6 SECURITY CONSIDERATIONS......................................103
    6.1 SECURITY THREATS .........................................103
      6.1.1 Spoofing the "Organizer" .............................103
      6.1.2 Spoofing the "Attendee" ..............................103
      6.1.3 Unauthorized Replacement of the Organizer ............104
      6.1.4 Eavesdropping ........................................104
      6.1.5 Flooding a Calendar ..................................104
      6.1.6 Procedural Alarms ....................................104
      6.1.7 Unauthorized REFRESH Requests ........................104
    6.2 RECOMMENDATIONS ..........................................104
      6.2.1 Use of [RFC-1847] to secure iTIP transactions ........105
      6.2.2 Implementation Controls ..............................105
   7 ACKNOWLEDGMENTS..............................................106
   8 BIBLIOGRAPHY.................................................106
   9 AUTHORS' ADDRESSES...........................................107
   10 FULL COPYRIGHT STATEMENT....................................109

Silverberg, et. al.         Standards Track                     [Page 4]

RFC 2446                          iTIP                     November 1998

1 Introduction

   This document specifies how calendaring systems use iCalendar objects
   to interoperate with other calendar systems. In particular, it
   specifies how to schedule events, to-dos, or daily journal entries.
   It further specifies how to search for available busy time
   information. It does so in a general way so as to allow multiple
   methods of communication between systems. Subsequent documents
   specify transport bindings between systems that use this protocol.

   This protocol is based on messages sent from an originator to one or
   more recipients. For certain types of messages, a recipient may
   reply, in order to update their status and may also return
   transaction/request status information. The protocol supports the
   ability for the message originator to modify or cancel the original
   message. The protocol also supports the ability for recipients to
   suggest changes to the originator of a message. The elements of the
   protocol also define the user roles for its transactions.

1.1 Formatting Conventions

   In order to refer to elements of the calendaring and scheduling
   model, core object or interoperability protocol defined in [iCAL] and
   [iTIP] several formatting conventions have been utilized.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].

   Calendaring and scheduling roles are referred to in quoted-strings of
   text with the first character of each word in upper case. For
   example, "Organizer" refers to a role of a "Calendar User"  (CU)
   within the scheduling protocol defined by [iTIP]. Calendar components
   defined by [iCAL] are referred to with capitalized, quoted-strings of
   text. All calendar components start with the letter "V". For example,
   "VEVENT" refers to the event calendar component, "VTODO" refers to
   the to-do calendar component and "VJOURNAL" refers to the daily
   journal calendar component. Scheduling methods defined by [iTIP] are
   referred to with capitalized, quoted-strings of text. For example,
   "REQUEST" refers to the method for requesting a scheduling calendar
   component be created or modified, "REPLY" refers to the method a
   recipient of a request uses to update their status with the
   "Organizer" of the calendar component.

   Properties defined by [iCAL] are referred to with capitalized,
   quoted-strings of text, followed by the word "property". For example,
   "ATTENDEE" property refers to the iCalendar property used to convey
   the calendar address of a "Calendar User". Property parameters

Silverberg, et. al.         Standards Track                     [Page 5]

RFC 2446                          iTIP                     November 1998

   defined by this memo are referred to with lower case, quoted-strings
   of text, followed by the word "parameter". For example, "value"
   parameter refers to the iCalendar property parameter used to override
   the default data type for a property value. Enumerated values defined
   by this memo are referred to with capitalized text, either alone or
   followed by the word "value".

   In tables, the quoted-string text is specified without quotes in
   order to minimize the table length.

1.2 Related Documents

   Implementers will need to be familiar with several other memos that,
   along with this one, describe the Internet calendaring and scheduling
   standards. This document, [iTIP], specifies an interoperability
   protocol for scheduling between different implementations. The
   related documents are:

        [iCAL] - specifies the objects, data types, properties and
        property parameters used in the protocols, along with the
        methods for representing and encoding them;

        [iMIP] specifies an Internet email binding for [iTIP].

   This memo does not attempt to repeat the specification of concepts or
   definitions from these other memos. Where possible, references are
   made to the memo that provides for the specification of these
   concepts or definitions.

1.3 ITIP Roles and Transactions

   ITIP defines methods for exchanging [iCAL] objects for the purposes
   of group calendaring and scheduling between "Calendar Users" (CUs).
   CUs take on one of two roles in iTIP. The CU who initiates an
   exchange takes on the role of "Organizer". For example, the CU who
   proposes a group meeting is the "Organizer". The CUs asked to
   participate in the group meeting by the "Organizer" take on the role
   of "Attendee". Note that "role" is also a descriptive parameter to
   the _ATTENDEE_ property. Its use is to convey descriptive context to
   an "Attendee" such as "chair", "req-participant" or "non-participant"
   and has nothing to do with the calendaring workflow.

Silverberg, et. al.         Standards Track                     [Page 6]

RFC 2446                          iTIP                     November 1998

   The ITIP methods are listed below and their usage and semantics are
   defined in section 3 of this document.

   +================+==================================================+
   | Method         |  Description                                     |
   |================+==================================================|
   | PUBLISH        | Used to publish a calendar entry to one or more  |
   |                | Calendar Users. There is no interactivity        |
   |                | between the publisher and any other calendar     |
   |                | user. An example might include a baseball team   |
   |                | publishing its schedule to the public.           |
   |                |                                                  |
   | REQUEST        | Used to schedule a calendar entry with other     |
   |                | Calendar Users. Requests are interactive in that |
   |                | they require the receiver to respond using       |
   |                | the Reply methods. Meeting Requests, Busy        |
   |                | Time requests and the assignment of VTODOs to    |
   |                | other Calendar Users are all examples.           |
   |                | Requests are also used by the "Organizer" to     |
   |                | update the status of a calendar entry.           |
   |                |                                                  |
   | REPLY          | A Reply is used in response to a Request to      |
   |                | convey "Attendee" status to the "Organizer".     |
   |                | Replies are commonly used to respond to meeting  |
   |                | and task requests.                               |
   |                |                                                  |
   | ADD            | Add one or more instances to an existing         |
   |                | VEVENT, VTODO, or VJOURNAL.                      |
   |                |                                                  |
   | CANCEL         | Cancel one or more instances of an existing      |
   |                | VEVENT, VTODO, or VJOURNAL.                      |
   |                |                                                  |
   | REFRESH        | The Refresh method is used by an "Attendee" to   |
   |                | request the latest version of a calendar entry.  |
   |                |                                                  |
   | COUNTER        | The Counter method is used by an "Attendee" to   |
   |                | negotiate a change in the calendar entry.        |
   |                | Examples include the request to change a         |
   |                | proposed Event time or change the due date for a |
   |                | VTODO.                                           |
   |                |                                                  |
   | DECLINE-       | Used by the "Organizer" to decline the proposed  |
   | COUNTER        | counter-proprosal.                               |
   +================+==================================================+

Silverberg, et. al.         Standards Track                     [Page 7]

RFC 2446                          iTIP                     November 1998

   Group scheduling in iTIP is accomplished using the set of "request"
   and "response" methods described above. The following table shows the
   methods broken down by who can send them.

   +================+==================================================+
   | Originator     | Methods                                          |
   |================+==================================================|
   | Organizer      | PUBLISH, REQUEST, ADD, CANCEL, DECLINECOUNTER    |
   |                |                                                  |
   | Attendee       | REPLY, REFRESH, COUNTER                          |
   |                | REQUEST only when delegating                     |
   +================+==================================================+

   Note that for some calendar component types, the allowable methods
   are a subset of the above set.

2 Interoperability Models

   There are two distinct protocols relevant to interoperability: an
   "Application Protocol" and a "Transport Protocol". The Application
   Protocol defines the content of the iCalendar objects sent between
   sender and receiver to accomplish the scheduling transactions listed
   above. The Transport Protocol defines how the iCalendar objects are
   sent between the sender and receiver. This document focuses on the
   Application Protocol. Binding documents such as [iMIP] focus on the
   Transport Protocol.

   The connection between Sender and Receiver in the diagram below
   refers to the Application Protocol. The iCalendar objects passed from
   the Sender to the Receiver are presented in Section 3, Application
   Protocol Elements.

   +----------+                      +----------+
   |          |        iTIP          |          |
   |  Sender  |<-------------------->| Receiver |
   |          |                      |          |
   +----------+                      +----------+

   There are several variations of this diagram in which the Sender and
   Receiver take on various roles of a "Calendar User Agent" (CUA) or a
   "Calendar Service" (CS).

   The architecture of iTIP is depicted in the diagram below. An
   application written to this specification may work with bindings for
   the store-and-forward transport, the real time transport, or both.
   Also note that iTIP could be bound to other transports.

Silverberg, et. al.         Standards Track                     [Page 8]

RFC 2446                          iTIP                     November 1998

   +------------------------------------------+
   |                   iTIP                   |
   +------------------------------------------+
   |Real-time | Store-and-Fwd | Other         |
   |Transport | Transport     | Transports... |
   +------------------------------------------+

2.1 Application Protocol

   In the iTIP model, a calendar entry is created and managed by an
   "Organizer". The "Organizer" interacts with other CUs by sending one
   or more of the iTIP messages listed above. "Attendees" use the
   "REPLY" method to communicate their status. "Attendees" do not make
   direct changes to the master calendar entry. They can, however, use
   the "COUNTER" method to suggest changes to the "Organizer". In any
   case, the "Organizer" has complete control over the master calendar
   entry.

2.1.1 Calendar Entry State

   There are two distinct states relevant to calendar entries: the
   overall state of the entry and the state associated with an
   "Attendee" to that entry.

   The state of an entry is defined by the "STATUS" property and is
   controlled by the "Organizer." There is no default value for the
   "STATUS" property. The "Organizer" sets the "STATUS" property to the
   appropriate value for each calendar entry.

   The state of a particular "Attendee" relative to an entry is defined
   by the "partstat" parameter in the "ATTENDEE" property for each
   "Attendee".  When an "Organizer" issues the initial entry, "Attendee"
   status is unknown. The "Organizer" specifies this by setting the
   "partstat" parameter to "NEEDS-ACTION". Each "Attendee" modifies
   their "ATTENDEE" property "partstat" parameter to an appropriate
   value as part of a "REPLY" message sent back to the "Organizer".

2.1.2 Delegation

   Delegation is defined as the process by which an "Attendee" grants
   another CU (or several CUs) the right to attend on their behalf. The
   "Organizer" is made aware of this change because the delegating
   "Attendee" informs the "Organizer". These steps are detailed in the
   REQUEST method section.

Silverberg, et. al.         Standards Track                     [Page 9]

RFC 2446                          iTIP                     November 1998

2.1.3 Acting on Behalf of other Calendar Users

   In many organizations one user will act on behalf of another to
   organize and/or respond to meeting requests. ITIP provides two
   mechanisms that support these activities.

   First, the "Organizer" is treated as a special entity, separate from
   "Attendees". All responses from "Attendees" flow to the "Organizer",
   making it easy to separate a calendar user organizing a meeting from
   calendar users attending the meeting. Additionally, iCalendar
   provides descriptive roles for each "Attendee". For instance, a role
   of "chair" may be ascribed to one or more "Attendees". The "chair"
   and the "Organizer" may or may not be the same calendar user. This
   maps well to scenarios where an assistant may manage meeting
   logistics for another individual who chairs a meeting.

   Second, a "sent-by" parameter may be specified in either the
   "Organizer" or "Attendee" properties. When specified, the "sent-by"
   parameter indicates that the responding CU acted on behalf of the
   specified "Attendee" or "Organizer".

2.1.4 Component Revisions

   The "SEQUENCE" property is used by the "Organizer" to indicate
   revisions to the calendar component. The rules for incrementing the
   "SEQUENCE" number are defined in [iCAL]. For clarity, these rules are
   paraphrased here in terms of how they are applied in [iTIP]. For a
   given "UID" in a calendar component:

   . For the "PUBLISH" and "REQUEST" methods, the "SEQUENCE" property
      value is incremented according to the rules defined in [iCAL].

   . The "SEQUENCE" property value MUST be incremented each time the
      "Organizer" uses the "ADD" or "CANCEL" methods.

   . The "SEQUENCE" property value MUST NOT be incremented when using
      "REPLY", "REFRESH", "COUNTER", "DECLINECOUNTER", or when sending a
      delegation "REQUEST".

   In some circumstances the "Organizer" may not have received responses
   to the final revision sent out. In this situation, the "Organizer"
   may wish to send an update "REQUEST", and set "RSVP=TRUE" for all
   "Attendees", so that current responses can be collected.

Silverberg, et. al.         Standards Track                    [Page 10]

RFC 2446                          iTIP                     November 1998

   The value of the "SEQUENCE" property contained in a response from an
   "Attendee" may not always match the "Organizer's" revision.
   Implementations may choose to have the CUA indicate to the CU that
   the response is to an entry that has been revised and allow the CU to
   decide whether or not to accept the response.

2.1.5 Message Sequencing

   CUAs that handle the [iTIP] application protocol must often correlate
   a component in a calendar store with a component received in the
   [iTIP] message. For example, an event may be updated with a later
   revision of the same event. To accomplish this, a CUA must correlate
   the version of the event already in its calendar store with the
   version sent in the [iTIP] message. In addition to this correlation,
   there are several factors that can cause [iTIP] messages to arrive in
   an unexpected order.  That is, an "Organizer" could receive a reply
   to an earlier revision of a component AFTER receiving a reply to a
   later revision.

   To maximize interoperability and to handle messages that arrive in an
   unexpected order, use the following rules:

   1.  The primary key for referencing a particular iCalendar component
       is the "UID" property value. To reference an instance of a
       recurring component, the primary key is composed of the "UID" and
       the "RECURRENCE-ID" properties.

   2.  The secondary key for referencing a component is the "SEQUENCE"
       property value.  For components where the "UID" is the same, the
       component with the highest numeric value for the "SEQUENCE"
       property obsoletes all other revisions of the component with
       lower values.

   3.  "Attendees" send "REPLY" messages to the "Organizer".  For
       replies where the "UID" property value is the same, the value of
       the "SEQUENCE" property indicates the revision of the component
       to which the "Attendee" is replying.  The reply with the highest
       numeric value for the "SEQUENCE" property obsoletes all other
       replies with lower values.

   4.  In situations where the "UID" and "SEQUENCE" properties match,
       the "DTSTAMP" property is used as the tie-breaker. The component
       with the latest "DTSTAMP" overrides all others. Similarly, for
       "Attendee" responses where the "UID" property values match and
       the "SEQUENCE" property values match, the response with the
       latest "DTSTAMP" overrides all others.

Silverberg, et. al.         Standards Track                    [Page 11]

RFC 2446                          iTIP                     November 1998

   Hence, CUAs must persist the following component properties: "UID",
   "RECURRENCE-ID", "SEQUENCE", and "DTSTAMP".  Furthermore, for each
   "ATTENDEE" property of a component CUAs must persist the "SEQUENCE"
   and "DTSTAMP" property values associated with the "Attendee's"
   response.

3 Application Protocol Elements

   ITIP messages are "text/calendar" MIME entities that contain
   calendaring and scheduling information. The particular type of [iCAL]
   message is referred to as the "method type". Each method type is
   identified by a "METHOD" property specified as part of the
   "text/calendar" content type.  The table below shows various
   combinations of calendar components and the method types that this
   memo supports.

   +=================================================+
   |         | VEVENT | VTODO | VJOURNAL | VFREEBUSY |
   |=================================================|
   |Publish  |  Yes   |  Yes  |  Yes     |   Yes     |
   |Request  |  Yes   |  Yes  |  No      |   Yes     |
   |Refresh  |  Yes   |  Yes  |  No      |   No      |
   |Cancel   |  Yes   |  Yes  |  Yes     |   No      |
   |Add      |  Yes   |  Yes  |  Yes     |   No      |
   |Reply    |  Yes   |  Yes  |  No      |   Yes     |
   |Counter  |  Yes   |  Yes  |  No      |   No      |
   |Decline- |        |       |          |           |
   |Counter  |  Yes   |  Yes  |  No      |   No      |
   +=================================================+

   Each method type is defined in terms of its associated components and
   properties. Some components and properties are required, some are
   optional and others are excluded. The restrictions are expressed in
   this document using a simple "restriction table". The first column
   indicates the name of a component or property. Properties of the
   iCalendar object are not indented. Properties of a component are
   indented. The second column contains "MUST" if the component or
   property must be present, "MAY" if the component or property is
   optional, and "NOT" if the component or property must not be present.
   Entries in the second column sometimes contain comments for further
   clarification.

Silverberg, et. al.         Standards Track                    [Page 12]

RFC 2446                          iTIP                     November 1998

3.1 Common Component Restriction Tables

   The restriction table below applies to properties of the iCalendar
   object. That is, the properties at the outermost scope. The presence
   column uses the following values to assert whether a property is
   required, is optional and the number of times it may appear in the
   iCalendar object.

   Presence Value       Description
   --------------------------------------------------------------
   1                 One instance MUST be present
   1+                At least one instance MUST be present
   0                 Instances of this property Must NOT be present
   0+                Multiple instances MAY be present
   0 or 1            Up to 1 instance of this property MAY be present
   ---------------------------------------------------------------

   The tables also call out "X-PROPERTY" and  "X-COMPONENT" to show
   where vendor-specific properties and components can appear.  The
   tables do not lay out the restrictions of property parameters. Those
   restrictions are defined in [iCAL].

   Component/Property  Presence
   ------------------- ----------------------------------------------
   CALSCALE            0 or 1
   PRODID              1
   VERSION             1       Value MUST be "2.0"
   X-PROPERTY          0+

   DateTime values MAY refer to a "VTIMEZONE" component. The property
   restrictions in the table below apply to any "VTIMEZONE" component in
   an ITIP message.

   Component/Property  Presence
   ------------------- ----------------------------------------------
   VTIMEZONE           0+      MUST be present if any date/time refers
                               to timezone
       DAYLIGHT        0+      MUST be one or more of either STANDARD or
                               DAYLIGHT
          COMMENT      0 or 1
          DTSTART      1       MUST be local time format
          RDATE        0+      if present RRULE MUST NOT be present
          RRULE        0+      if present RDATE MUST NOT be present
          TZNAME       0 or 1
          TZOFFSET     1
          TZOFFSETFROM 1
          TZOFFSETTO   1

Silverberg, et. al.         Standards Track                    [Page 13]

RFC 2446                          iTIP                     November 1998

          X-PROPERTY   0+
       LAST-MODIFIED   0 or 1
       STANDARD        0+      MUST be one or more of either STANDARD or
                               DAYLIGHT
          COMMENT      0 or 1
          DTSTART      1       MUST be local time format
          RDATE        0+      if present RRULE MUST NOT be present
          RRULE        0+      if present RDATE MUST NOT be present
          TZNAME       0 or 1
          TZOFFSETFROM 1
          TZOFFSETTO   1
          X-PROPERTY   0+
       TZID            1
       TZURL           0 or 1
       X-PROPERTY      0+

   The property restrictions in the table below apply to any "VALARM"
   component in an ITIP message.

   Component/Property  Presence
   ------------------- ----------------------------------------------
   VALARM              0+
       ACTION          1
       ATTACH          0+
       DESCRIPTION     0 or 1
       DURATION        0 or 1  if present REPEAT MUST be present
       REPEAT          0 or 1  if present DURATION MUST be present
       SUMMARY         0 or 1
       TRIGGER         1
       X-PROPERTY      0+

3.2 Methods for VEVENT Calendar Components

   This section defines the property set restrictions for the method
   types that are applicable to the "VEVENT" calendar component. Each
   method is defined using a table that clarifies the property
   constraints that define the particular method.

Silverberg, et. al.         Standards Track                    [Page 14]

RFC 2446                          iTIP                     November 1998

   The following summarizes the methods that are defined for the
   "VEVENT" calendar component.

   +================+==================================================+
   | Method         |  Description                                     |
   |================+==================================================|
   | PUBLISH        | Post notification of an event. Used primarily as |
   |                | a method of advertising the existence of an      |
   |                | event.                                           |
   |                |                                                  |
   | REQUEST        | Make a request for an event. This is an explicit |
   |                | invitation to one or more "Attendees". Event     |
   |                | Requests are also used to update or change an    |
   |                | existing event. Clients that cannot handle       |
   |                | REQUEST may degrade the event to view it as an   |
   |                | PUBLISH.                                         |
   |                |                                                  |
   | REPLY          | Reply to an event request. Clients may set their |
   |                | status ("partstat") to ACCEPTED, DECLINED,       |
   |                | TENTATIVE, or DELEGATED.                         |
   |                |                                                  |
   | ADD            | Add one or more instances to an existing event.  |
   |                |                                                  |
   | CANCEL         | Cancel one or more instances of an existing      |
   |                | event.                                           |
   |                |                                                  |
   | REFRESH        | A request is sent to an "Organizer" by an        |
   |                | "Attendee" asking for the latest version of an   |
   |                | event to be resent to the requester.             |
   |                |                                                  |
   | COUNTER        | Counter a REQUEST with an alternative proposal,  |
   |                | Sent by an "Attendee" to the "Organizer".        |
   |                |                                                  |
   | DECLINECOUNTER | Decline a counter proposal. Sent to an           |
   |                | "Attendee" by the "Organizer".                   |
   +================+==================================================+

3.2.1 PUBLISH

   The "PUBLISH" method in a "VEVENT" calendar component is an
   unsolicited posting of an iCalendar object. Any CU may add published
   components to their calendar. The "Organizer" MUST be present in a
   published iCalendar component. "Attendees" MUST NOT be present. Its
   expected usage is for encapsulating an arbitrary event as an
   iCalendar object. The "Organizer" may subsequently update (with
   another "PUBLISH" method), add instances to (with an "ADD" method),
   or cancel (with a "CANCEL" method) a previously published "VEVENT"
   calendar component.

Silverberg, et. al.         Standards Track                    [Page 15]

RFC 2446                          iTIP                     November 1998

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1       MUST equal "PUBLISH"
VEVENT              1+
     DTSTAMP        1
     DTSTART        1
     ORGANIZER      1
     SUMMARY        1       Can be null.
     UID            1
     RECURRENCE-ID  0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise
                            it MUST NOT be present.
     SEQUENCE       0 or 1  MUST be present if value is greater than
                            0, MAY be present if 0
     ATTACH         0+
     CATEGORIES     0 or 1  This property may contain a list of
                            values
     CLASS          0 or 1
     COMMENT        0 or 1
     CONTACT        0+
     CREATED        0 or 1
     DESCRIPTION    0 or 1  Can be null
     DTEND          0 or 1  if present DURATION MUST NOT be present
     DURATION       0 or 1  if present DTEND MUST NOT be present
     EXDATE         0+
     EXRULE         0+
     GEO            0 or 1
     LAST-MODIFIED  0 or 1
     LOCATION       0 or 1
     PRIORITY       0 or 1
     RDATE          0+
     RELATED-TO     0+
     RESOURCES      0 or 1 This property MAY contain a list of values
     RRULE          0+
     STATUS         0 or 1 MAY be one of TENTATIVE/CONFIRMED/CANCELLED
     TRANSP         0 or 1
     URL            0 or 1
     X-PROPERTY     0+

     ATTENDEE       0
     REQUEST-STATUS 0

VALARM              0+
VFREEBUSY           0
VJOURNAL            0

Silverberg, et. al.         Standards Track                    [Page 16]

RFC 2446                          iTIP                     November 1998

VTODO               0
VTIMEZONE           0+    MUST be present if any date/time refers to
                          a timezone
X-COMPONENT         0+

3.2.2 REQUEST

   The "REQUEST" method in a "VEVENT" component provides the following
   scheduling functions:

     .  Invite "Attendees" to an event;
     .  Reschedule an existing event;
     .  Response to a REFRESH request;
     .  Update the details of an existing event, without rescheduling it;
     .  Update the status of "Attendees" of an existing event, without
        rescheduling it;
     .  Reconfirm an existing event, without rescheduling it;
     .  Forward a "VEVENT" to another uninvited CU.
     .  For an existing "VEVENT" calendar component, delegate the role of
        "Attendee" to another CU;
     .  For an existing "VEVENT" calendar component, changing the role of
        "Organizer" to another CU.

   The "Organizer" originates the "REQUEST". The recipients of the
   "REQUEST" method are the CUs invited to the event, the "Attendees".
   "Attendees" use the "REPLY" method to convey attendance status to the
   "Organizer".

   The "UID" and "SEQUENCE" properties are used to distinguish the
   various uses of the "REQUEST" method. If the "UID" property value in
   the "REQUEST" is not found on the recipient's calendar, then the
   "REQUEST" is for a new "VEVENT" calendar component. If the "UID"
   property value is found on the recipient's calendar, then the
   "REQUEST" is for a rescheduling, an update, or a reconfirm of the
   "VEVENT" calendar component.

   For the "REQUEST" method, multiple "VEVENT" components in a single
   iCalendar object are only permitted when for components with the same
   "UID" property.  That is, a series of recurring events may have
   instance-specific information.  In this case, multiple "VEVENT"
   components are needed to express the entire series.

Silverberg, et. al.         Standards Track                    [Page 17]

RFC 2446                          iTIP                     November 1998

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
-----------------------------------------------------------------
METHOD              1       MUST be "REQUEST"
VEVENT              1+      All components MUST have the same UID
    ATTENDEE        1+
    DTSTAMP         1
    DTSTART         1
    ORGANIZER       1
    SEQUENCE        0 or 1  MUST be present if value is greater than 0,
                            MAY be present if 0
    SUMMARY         1       Can be null
    UID             1

    ATTACH          0+
    CATEGORIES      0 or 1  This property may contain a list of values
    CLASS           0 or 1
    COMMENT         0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1  Can be null
    DTEND           0 or 1  if present DURATION MUST NOT be present
    DURATION        0 or 1  if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1
    RDATE           0+
    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.
    RELATED-TO      0+
    REQUEST-STATUS  0+
    RESOURCES       0 or 1  This property MAY contain a list of values
    RRULE           0+
    STATUS          0 or 1  MAY be one of TENTATIVE/CONFIRMED
    TRANSP          0 or 1
    URL             0 or 1
    X-PROPERTY      0+

VALARM              0+
VTIMEZONE           0+      MUST be present if any date/time refers to
                            a timezone
X-COMPONENT         0+

Silverberg, et. al.         Standards Track                    [Page 18]

RFC 2446                          iTIP                     November 1998

VFREEBUSY           0
VJOURNAL            0
VTODO               0

3.2.2.1 Rescheduling an Event

   The "REQUEST" method may be used to reschedule an event. A
   rescheduled event involves a change to the existing event in terms of
   its time or recurrence intervals and possibly the location or
   description. If the recipient CUA of a "REQUEST" method finds that
   the "UID" property value already exists on the calendar, but that the
   "SEQUENCE" (or "DTSTAMP") property value in the "REQUEST" method is
   greater than the value for the existing event, then the "REQUEST"
   method describes a rescheduling of the event.

3.2.2.2 Updating or Reconfirmation of an Event

   The "REQUEST" method may be used to update or reconfirm an event. An
   update to an existing event does not involve changes to the time or
   recurrence intervals, and might not involve a change to the location
   or description for the event. If the recipient CUA of a "REQUEST"
   method finds that the "UID" property value already exists on the
   calendar and that the "SEQUENCE" property value in the "REQUEST" is
   the same as the value for the existing event, then the "REQUEST"
   method describes an update of the event details, but no rescheduling
   of the event.

   The update "REQUEST" method is the appropriate response to a
   "REFRESH" method sent from an "Attendee" to the "Organizer" of an
   event.

   The "Organizer" of an event may also send unsolicited "REQUEST"
   methods.  The unsolicited "REQUEST" methods may be used to update the
   details of the event without rescheduling it, to update the
   "partstat" parameter of "Attendees", or to reconfirm the event.

3.2.2.3 Delegating an Event to another CU

   Some calendar and scheduling systems allow "Attendees" to delegate
   their presence at an event to another calendar user. ITIP supports
   this concept using the following workflow. Any "Attendee" may
   delegate their right to participate in a calendar VEVENT to another
   CU. The implication is that the delegate participates in lieu of the
   original "Attendee"; NOT in addition to the "Attendee". The delegator
   MUST notify the "Organizer" of this action using the steps outlined
   below.  Implementations may support or restrict delegation as they
   see fit. For instance, some implementations may restrict a delegate
   from delegating a "REQUEST" to another CU.

Silverberg, et. al.         Standards Track                    [Page 19]

RFC 2446                          iTIP                     November 1998

   The "Delegator" of an event forwards the existing "REQUEST" to the
   "Delegate". The "REQUEST" method MUST include an "ATTENDEE" property
   with the calendar address of the "Delegate". The "Delegator" MUST
   also send a "REPLY" method to the "Organizer" with the "Delegator's"
   "ATTENDEE" property "partstat" parameter value set to "delegated". In
   addition, the "delegated-to" parameter MUST be included with the
   calendar address of the "Delegate".

   In response to the request, the "Delegate" MUST send a "REPLY" method
   to the "Organizer" and optionally, to the "Delegator". The "REPLY"
   method " SHOULD include the "ATTENDEE" property with the "delegated-
   from" parameter value of the "Delegator's" calendar address.

   The "Delegator" may continue to receive updates to the event even
   though they will not be attending. This is accomplished by the
   "Delegator" setting their "role" attribute to " NON-PARTICIPANT" in
   the "REPLY" to the "Organizer"

3.2.2.4 Changing the Organizer

   The situation may arise where the "Organizer" of a VEVENT is no
   longer able to perform the "Organizer" role and abdicates without
   passing on the "Organizer" role to someone else. When this occurs the
   "Attendees" of the VEVENT may use out-of-band mechanisms to
   communicate the situation and agree upon a new "Organizer".  The new
   "Organizer" should then send out a new "REQUEST" with a modified
   version of the VEVENT in which the "SEQUENCE" number has been
   incremented and value of the "ORGANIZER" property has been changed to
   the calendar address of the new "Organizer".

3.2.2.5 Sending on Behalf of the Organizer

   There are a number of scenarios that support the need for a calendar
   user to act on behalf of the "Organizer" without explicit role
   changing.  This might be the case if the CU designated as "Organizer"
   was sick or unable to perform duties associated with that function.
   In these cases iTIP supports the notion of one CU acting on behalf of
   another. Using the "sent-by" parameter, a calendar user could send an
   updated "VEVENT" REQUEST. In the case where one CU sends on behalf of
   another CU, the "Attendee" responses are still directed back towards
   the CU designated as "Organizer".

3.2.2.6 Forwarding to An Uninvited CU

   An "Attendee" invited to an event may invite another uninvited CU to
   the event. The invited "Attendee" accomplishes this by forwarding the
   original "REQUEST" method to the uninvited CU. The "Organizer"
   decides whether or not the uninvited CU is added to the attendee

Silverberg, et. al.         Standards Track                    [Page 20]

RFC 2446                          iTIP                     November 1998

   list. If the "Organizer" decides not to add the uninvited CU no
   further action is required, however the "Organizer" MAY send the
   uninvited CU a "CANCEL" message.  If the "Organizer" decides to add
   an uninvited CU, a new "ATTENDEE" property is added for the uninvited
   CU with its property parameters set as the "Organizer" deems
   appropriate. When forwarding a "REQUEST" to another CU, the
   forwarding "Attendee" MUST NOT make changes to the VEVENT property
   set.

3.2.2.7 Updating Attendee Status

   The "Organizer" of an event may also request updated status from one
   or more "Attendees. The "Organizer" sends a "REQUEST" method to the
   "Attendee" and sets the "ATTENDEE;RSVP=TRUE" property parameter. The
   "SEQUENCE" property for the event is not changed from its previous
   value. A recipient will determine that the only change in the
   "REQUEST" is that their "RSVP" property parameter indicates a request
   for updated status. The recipient SHOULD respond with a "REPLY"
   method indicating their current status with respect to the "REQUEST".

3.2.3 REPLY

   The "REPLY" method in a "VEVENT" calendar component is used to
   respond (e.g., accept or decline) to a "REQUEST" or to reply to a
   delegation "REQUEST". When used to provide a delegation response, the
   "Delegator" SHOULD include the calendar address of the "Delegate" on
   the "delegated-to" property parameter of the "Delegator's" "ATTENDEE"
   property. The "Delegate" SHOULD include the calendar address of the
   "Delegator" on the "delegated-from" property parameter of the
   "Delegate's" "ATTENDEE" property.

   The "REPLY" method may also be used to respond to an unsuccessful
   "REQUEST" method. Depending on the value of the "REQUEST-STATUS"
   property no scheduling action may have been performed.

   The "Organizer" of an event may receive the "REPLY" method from a CU
   not in the original "REQUEST". For example, a "REPLY" may be received
   from a "Delegate" to an event. In addition, the "REPLY" method may be
   received from an unknown CU (a "Party Crasher"). This uninvited
   "Attendee" may be accepted, or the "Organizer" may cancel the event
   for the uninvited "Attendee" by sending a "CANCEL" method to the
   uninvited "Attendee".

   An "Attendee" can include a message to the "Organizer" using the
   "COMMENT" property. For example, if the user indicates tentative
   acceptance and wants to let the "Organizer" know why, the reason can
   be expressed in the "COMMENT" property value.

Silverberg, et. al.         Standards Track                    [Page 21]

RFC 2446                          iTIP                     November 1998

   The "Organizer" may also receive a "REPLY" from one CU on behalf of
   another. Like the scenario enumerated above for the "Organizer",
   "Attendees" may have another CU respond on their behalf. This is done
   using the "sent-by" parameter.

   The optional properties listed in the table below (those listed as
   "0+" or "0 or 1") MUST NOT be changed from those of the original
   request.  If property changes are desired the COUNTER message must be
   used.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1       MUST be "REPLY"
VEVENT              1+      All components MUST have the same UID
    ATTENDEE        1       MUST be the address of the Attendee
                            replying.
    DTSTAMP         1
    ORGANIZER       1
    RECURRENCE-ID   0 or 1  only if referring to an instance of a
                            recurring calendar component.  Otherwise
                            it must NOT be present.
    UID             1       MUST be the UID of the original REQUEST

    SEQUENCE        0 or 1  MUST if non-zero, MUST be the sequence
                            number of the original REQUEST. MAY be
                            present if 0.

    ATTACH          0+
    CATEGORIES      0 or 1  This property may contain a list of values
    CLASS           0 or 1
    COMMENT         0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1
    DTEND           0 or 1  if present DURATION MUST NOT be present
    DTSTART         0 or 1
    DURATION        0 or 1  if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1
    RDATE           0+
    RELATED-TO      0+

Silverberg, et. al.         Standards Track                    [Page 22]

RFC 2446                          iTIP                     November 1998

    RESOURCES       0 or 1  This property MAY contain a list of values
    REQUEST-STATUS  0+
    RRULE           0+
    STATUS          0 or 1
    SUMMARY         0 or 1
    TRANSP          0 or 1
    URL             0 or 1
    X-PROPERTY      0+

VTIMEZONE           0 or 1 MUST be present if any date/time refers
                           to a timezone
X-COMPONENT         0+

VALARM              0
VFREEBUSY           0
VJOURNAL            0
VTODO               0

3.2.4 ADD

   The "ADD" method in a "VEVENT" calendar component is used to add one
   or more instances to an existing "VEVENT". Unlike the "REQUEST"
   method, when using issuing an "ADD" method, the "Organizer" does not
   send the full "VEVENT" description; only the new instance(s). The
   "ADD" method is especially useful if there are instance-specific
   properties to be preserved in a recurring "VEVENT". For instance, an
   "Organizer" may have originally scheduled a weekly Thursday meeting.
   At some point, several instances changed. Location or start time may
   have changed, or some instances may have unique "DESCRIPTION"
   properties. The "ADD" method allows the "Organizer" to add new
   instances to an existing event using a single ITIP message without
   redefining the entire recurring pattern.

   The "UID" must be that of the existing event. If the "UID" property
   value in the "ADD" is not found on the recipient's calendar, then the
   recipient SHOULD send a "REFRESH" to the "Organizer" in order to be
   updated with the latest version of the "VEVENT".  If an "Attendee"
   implementation does not support the "ADD" method it should respond
   with a "REQUEST-STATUS" value of 3.14 and ask for a "REFRESH".

   This method type is an iCalendar object that conforms to the
   following property constraints:

Silverberg, et. al.         Standards Track                    [Page 23]

RFC 2446                          iTIP                     November 1998

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "ADD"
VEVENT              1
    DTSTAMP         1
    DTSTART         1
    ORGANIZER       1
    SEQUENCE        1      MUST be greater than 0
    SUMMARY         1      Can be null
    UID             1      MUST match that of the original event

    ATTACH          0+
    ATTENDEE        0+
    CATEGORIES      0 or 1 This property MAY contain a list of values
    CLASS           0 or 1
    COMMENT         0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1  Can be null
    DTEND           0 or 1  if present DURATION MUST NOT be present
    DURATION        0 or 1  if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1
    RDATE           0+
    RELATED-TO      0+
    RESOURCES       0 or 1  This property MAY contain a list of values
    RRULE           0+
    STATUS          0 or 1  MAY be one of TENTATIVE/CONFIRMED
    TRANSP          0 or 1
    URL             0 or 1
    X-PROPERTY      0+

    RECURRENCE-ID   0
    REQUEST-STATUS  0

VALARM              0+
VTIMEZONE           0+     MUST be present if any date/time refers to
                           a timezone
X-COMPONENT         0+

VFREEBUSY           0
VTODO               0
VJOURNAL            0

Silverberg, et. al.         Standards Track                    [Page 24]

RFC 2446                          iTIP                     November 1998

3.2.5 CANCEL

   The "CANCEL" method in a "VEVENT" calendar component is used to send
   a cancellation notice of an existing event request to the
   "Attendees". The message is sent by the "Organizer" of the event. For
   a recurring event, either the whole event or instances of an event
   may be cancelled. To cancel the complete range of recurring event,
   the "UID" property value for the event MUST be specified and a
   "RECURRENCE-ID" MUST NOT be specified in the "CANCEL" method. In
   order to cancel an individual instance of the event, the
   "RECURRENCE-ID" property value for the event MUST be specified in the
   "CANCEL" method.

   There are two options for canceling a sequence of instances of a
   recurring "VEVENT" calendar component:

   (a) the "RECURRENCE-ID" property for an instance in the sequence MUST
       be specified with the "RANGE" property parameter value of
       THISANDPRIOR (or THISANDFUTURE)  to indicate cancellation of the
       specified "VEVENT" calendar component and all instances before
       (or after); or

   (b) individual recurrence instances may be cancelled by specifying
       multiple "RECURRENCE-ID" properties corresponding to the
       instances to be cancelled.

   When a "VEVENT" is cancelled, the "SEQUENCE" property value MUST be
   incremented.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "CANCEL"

VEVENT              1+     All must have the same UID
    ATTENDEE        0+     MUST include all "Attendees" being removed
                           the event. MUST include all "Attendees" if
                           the entire event is cancelled.
    DTSTAMP         1
    ORGANIZER       1
    SEQUENCE        1
    UID             1       MUST be the UID of the original REQUEST

    COMMENT         0 or 1
    ATTACH          0+
    CATEGORIES      0 or 1  This property may contain a list of values

Silverberg, et. al.         Standards Track                    [Page 25]

RFC 2446                          iTIP                     November 1998

    CLASS           0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1
    DTEND           0 or 1 if present DURATION MUST NOT be present
    DTSTART         0 or 1
    DURATION        0 or 1 if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1
    RDATE           0+
    RECURRENCE-ID   0 or 1  MUST be present if referring to one or
                            more or more recurring instances.
                            Otherwise it MUST NOT be present
    RELATED-TO      0+
    RESOURCES       0 or 1
    RRULE           0+
    STATUS          0 or 1  MUST be set to CANCELLED. If uninviting
                            specific "Attendees" then MUST NOT be
                            included.
    SUMMARY         0 or 1
    TRANSP          0 or 1
    URL             0 or 1
    X-PROPERTY      0+
    REQUEST-STATUS  0

VTIMEZONE           0+     MUST be present if any date/time refers to
                           a timezone
X-COMPONENT         0+

VTODO               0
VJOURNAL            0
VFREEBUSY           0
VALARM              0

3.2.6 REFRESH

   The "REFRESH" method in a "VEVENT" calendar component is used by
   "Attendees" of an existing event to request an updated description
   from the event "Organizer". The "REFRESH" method must specify the
   "UID" property of the event to update. A recurrence instance of an
   event may be requested by specifying the "RECURRENCE-ID" property
   corresponding to the associated event. The "Organizer" responds with
   the latest description and version of the event.

Silverberg, et. al.         Standards Track                    [Page 26]

RFC 2446                          iTIP                     November 1998

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "REFRESH"

VEVENT              1
    ATTENDEE        1      MUST be the address of requestor
    DTSTAMP         1
    ORGANIZER       1
    UID             1      MUST be the UID associated with original
                           REQUEST
    COMMENT         0 or 1
    RECURRENCE-ID   0 or 1 MUST only if referring to an instance of a
                           recurring calendar component.  Otherwise
                           it must NOT be present.
    X-PROPERTY      0+

    ATTACH          0
    CATEGORIES      0
    CLASS           0
    CONTACT         0
    CREATED         0
    DESCRIPTION     0
    DTEND           0
    DTSTART         0
    DURATION        0
    EXDATE          0
    EXRULE          0
    GEO             0
    LAST-MODIFIED   0
    LOCATION        0
    PRIORITY        0
    RDATE           0
    RELATED-TO      0
    REQUEST-STATUS  0
    RESOURCES       0
    RRULE           0
    SEQUENCE        0
    STATUS          0
    SUMMARY         0
    TRANSP          0
    URL             0

X-COMPONENT         0+

VTODO               0

Silverberg, et. al.         Standards Track                    [Page 27]

RFC 2446                          iTIP                     November 1998

VJOURNAL            0
VFREEBUSY           0
VTIMEZONE           0
VALARM              0

3.2.7 COUNTER

   The "COUNTER" method for a "VEVENT" calendar component is used by an
   "Attendee" of an existing event to submit to the "Organizer" a
   counter proposal to the event description. The "Attendee" sends this
   message to the "Organizer" of the event.

   The counter proposal is an iCalendar object consisting of a VEVENT
   calendar component describing the complete description of the
   alternate event.

   The "Organizer" rejects the counter proposal by sending the
   "Attendee" a VEVENT "DECLINECOUNTER" method. The "Organizer" accepts
   the counter proposal by rescheduling the event as described in
   section 3.2.2.1 Rescheduling an Event.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "COUNTER"

VEVENT              1
    DTSTAMP         1
    DTSTART         1
    ORGANIZER       1       MUST be the "Organizer" of the original
                            event
    SEQUENCE        1       MUST be present if value is greater than 0,
                            MAY be present if 0
    SUMMARY         1       Can be null
    UID             1       MUST be the UID associated with the REQUEST
                            being countered

    ATTACH          0+
    ATTENDEE        0+      Can also  be used to propose other
                            "Attendees"
    CATEGORIES      0 or 1  This property may contain a list of values
    CLASS           0 or 1
    COMMENT         0 or 1
    CONTACT         0+
    CREATED         0 or 1
    DESCRIPTION     0 or 1

Silverberg, et. al.         Standards Track                    [Page 28]

RFC 2446                          iTIP                     November 1998

    DTEND           0 or 1  if present DURATION MUST NOT be present
    DURATION        0 or 1  if present DTEND MUST NOT be present
    EXDATE          0+
    EXRULE          0+
    GEO             0 or 1
    LAST-MODIFIED   0 or 1
    LOCATION        0 or 1
    PRIORITY        0 or 1
    RDATE           0+
    RECURRENCE-ID   0 or 1  MUST only if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.
    RELATED-TO      0+
    REQUEST-STATUS  0+
    RESOURCES       0 or 1  This property may contain a list of values
    RRULE           0+
    STATUS          0 or 1  Value must be one of CONFIRMED/TENATIVE/
                            CANCELLED
    TRANSP          0 or 1
    URL             0 or 1
    X-PROPERTY      0+

VALARM              0+
VTIMEZONE           0+      MUST be present if any date/time refers to
                            a timezone
X-COMPONENT         0+

VTODO               0
VJOURNAL            0
VFREEBUSY           0

3.2.8 DECLINECOUNTER

   The "DECLINECOUNTER" method in a "VEVENT" calendar component is used
   by the "Organizer" of an event to reject a counter proposal submitted
   by an "Attendee". The "Organizer" must send the "DECLINECOUNTER"
   message to the "Attendee" that sent the "COUNTER" method to the
   "Organizer".

   This method type is an iCalendar object that conforms to the
   following property constraints:

Silverberg, et. al.         Standards Track                    [Page 29]

RFC 2446                          iTIP                     November 1998

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "DECLINECOUNTER"

VEVENT              1
    DTSTAMP         1
    ORGANIZER       1
    UID             1       MUST, same UID specified in original
                            REQUEST and subsequent COUNTER
    COMMENT         0 or 1
    RECURRENCE-ID   0 or 1  MUST only if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.
    REQUEST-STATUS  0+
    SEQUENCE        0 OR 1  MUST be present if value is greater than 0,
                            MAY be present if 0
    X-PROPERTY      0+
    ATTACH          0
    ATTENDEE        0
    CATEGORIES      0
    CLASS           0
    CONTACT         0
    CREATED         0
    DESCRIPTION     0
    DTEND           0
    DTSTART         0
    DURATION        0
    EXDATE          0
    EXRULE          0
    GEO             0
    LAST-MODIFIED   0
    LOCATION        0
    PRIORITY        0
    RDATE           0
    RELATED-TO      0
    RESOURCES       0
    RRULE           0
    STATUS          0
    SUMMARY         0
    TRANSP          0
    URL             0

X-COMPONENT         0+
VTODO               0
VJOURNAL            0
VFREEBUSY           0
VTIMEZONE           0
VALARM              0

Silverberg, et. al.         Standards Track                    [Page 30]

RFC 2446                          iTIP                     November 1998

3.3 Methods For VFREEBUSY Components

   This section defines the property set for the methods that are
   applicable to the "VFREEBUSY" calendar component. Each of the methods
   is defined using a restriction table.

   This document only addresses the transfer of busy time information.
   Applications desiring free time information MUST infer this from
   available busy time information.

   The busy time information within the iCalendar object MAY be grouped
   into more than one "VFREEBUSY" calendar component. This capability
   allows busy time periods to be grouped according to some common
   periodicity, such as a calendar week, month, or year. In this case,
   each "VFREEBUSY" calendar component MUST include the "ATTENDEE",
   "DTSTART" and "DTEND" properties in order to specify the source of
   the busy time information and the date and time interval over which
   the busy time information covers.

   The "FREEBUSY" property value MAY include a list of values, separated
   by the COMMA character ([US-ASCII] decimal 44). Alternately, multiple
   busy time periods MAY be specified with multiple instances of the
   "FREEBUSY" property. Both forms MUST be supported by implementations
   conforming to this document. Duplicate busy time periods SHOULD NOT
   be specified in an iCalendar object. However, two different busy time
   periods MAY overlap.

   "FREEBUSY" properties should be sorted such that their values are in
   ascending order, based on the start time, and then the end time, with
   the earliest periods first. For example, today's busy time
   information should appear after yesterday's busy time information.
   And the busy time for this half-hour should appear after the busy
   time for earlier today.

   Since events may span a day boundary, free busy time period may also
   span a day boundary. Individual "A" requests busy time from
   individuals "B", "C" and "D". Individual "B" and "C" replies with
   busy time data to individual "A". Individual "D" does not support
   busy time requests and does not reply with any data. If the transport
   binding supports exception messages, then individual "D" returns an
   "unsupported capability" message to individual "A4.34.3".

   The following summarizes the methods that are defined for the
   "VFREEBUSY" calendar component.

Silverberg, et. al.         Standards Track                    [Page 31]

RFC 2446                          iTIP                     November 1998

   |================|==================================================|
   | Method         |  Description                                     |
   |================|==================================================|
   | PUBLISH        | Publish unsolicited busy time data.              |
   | REQUEST        | Request busy time data.                          |
   | REPLY          | Reply to a busy time request.                    |
   |================|==================================================|

3.3.1 PUBLISH

   The "PUBLISH" method in a "VFREEBUSY" calendar component is used to
   publish busy time data. The method may be sent from one CU to any
   other.  The purpose of the method is to provide a message for sending
   unsolicited busy time data. That is, the busy time data is not being
   sent as a "REPLY" to the receipt of a "REQUEST" method.

   The "ATTENDEE" property must be specified in the busy time
   information.  The value is the CU address of the originator of the
   busy time information.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1       MUST be "PUBLISH"

VFREEBUSY           1+
    DTSTAMP         1
    DTSTART         1       DateTime values must be in UTC
    DTEND           1       DateTime values must be in UTC
    FREEBUSY        1+      MUST be BUSYTIME. Multiple instances are
                            allowed. Multiple instances must be sorted
                            in ascending order
    ORGANIZER       1       MUST contain the address of originator of
                            busy time data.

    COMMENT         0 or 1
    CONTACT         0+
    X-PROPERTY      0+
    URL             0 or 1  Specifies busy time URL

    ATTENDEE        0
    DURATION        0
    REQUEST-STATUS  0
    UID             0

X-COMPONENT         0+

Silverberg, et. al.         Standards Track                    [Page 32]

RFC 2446                          iTIP                     November 1998

VEVENT              0
VTODO               0
VJOURNAL            0
VTIMEZONE           0
VALARM              0

3.3.2 REQUEST

   The "REQUEST" method in a "VFREEBUSY" calendar component is used to
   ask a "Calendar User" for their busy time information. The request
   may be for a busy time information bounded by a specific date and
   time interval.

   This message only permits requests for busy time information. The
   message is sent from a "Calendar User" requesting the busy time
   information to one or more intended recipients.

   If the originator of the "REQUEST" method is not authorized to make a
   busy time request on the recipient's calendar system, then an
   exception message SHOULD be returned in a "REPLY" method, but no busy
   time data need be returned.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "REQUEST"

VFREEBUSY           1
    ATTENDEE        1+     contain the address of the calendar store
    DTEND           1      DateTime values must be in UTC
    DTSTAMP         1
    DTSTART         1      DateTime values must be in UTC
    ORGANIZER       1      MUST be the request originator's address
    UID             1
    COMMENT         0 or 1
    CONTACT         0+
    X-PROPERTY      0+

    FREEBUSY        0
    DURATION        0
    REQUEST-STATUS  0
    URL             0

X-COMPONENT         0+
VALARM              0
VEVENT              0

Silverberg, et. al.         Standards Track                    [Page 33]

RFC 2446                          iTIP                     November 1998

VTODO               0
VJOURNAL            0
VTIMEZONE           0

3.3.3 REPLY

   The "REPLY" method in a "VFREEBUSY" calendar component is used to
   respond to a busy time request. The method is sent by the recipient
   of a busy time request to the originator of the request.

   The "REPLY" method may also be used to respond to an unsuccessful
   "REQUEST" method. Depending on the "REQUEST-STATUS" value, no busy
   time information may be returned.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD              1      MUST be "REPLY"

VFREEBUSY           1
    ATTENDEE        1      (address of recipient replying)
    DTSTAMP         1
    DTEND           1      DateTime values must be in UTC
    DTSTART         1      DateTime values must be in UTC
    FREEBUSY        1+      (values MUST all be of the same data
                            type. Multiple instances are allowed.
                            Multiple instances MUST be sorted in
                            ascending order. Values MAY NOT overlap)
    ORGANIZER       1       MUST be the request originator's address
    UID             1

    COMMENT         0 or 1
    CONTACT         0+
    REQUEST-STATUS  0+
    URL             0 or 1  (specifies busy time URL)
    X-PROPERTY      0+
    DURATION        0
    SEQUENCE        0

X-COMPONENT         0+
VALARM              0
VEVENT              0
VTODO               0
VJOURNAL            0
VTIMEZONE           0

Silverberg, et. al.         Standards Track                    [Page 34]

RFC 2446                          iTIP                     November 1998

3.4 Methods For VTODO Components

   This section defines the property set for the methods that are
   applicable to the "VTODO" calendar component. Each of the methods is
   defined using a restriction table that specifies the property
   constraints that define the particular method.

   The following summarizes the methods that are defined for the "VTODO"
   calendar component.

   +================+==================================================+
   | Method         |  Description                                     |
   |================+==================================================|
   | PUBLISH        | Post notification of a VTODO. Used primarily as  |
   |                | a method of advertising the existence of a VTODO.|
   |                |                                                  |
   | REQUEST        | Assign a VTODO. This is an explicit assignment to|
   |                | one or more Calendar Users. The REQUEST method   |
   |                | is also used to update or change an existing     |
   |                | VTODO. Clients that cannot handle REQUEST MAY    |
   |                | degrade the method to treat it as a PUBLISH.     |
   |                |                                                  |
   | REPLY          | Reply to a VTODO request. Attendees MAY set      |
   |                | PARTSTAT to ACCEPTED, DECLINED, TENTATIVE,       |
   |                | DELEGATED, PARTIAL, and COMPLETED.               |
   |                |                                                  |
   | ADD            | Add one or more instances to an existing to-do.  |
   |                |                                                  |
   | CANCEL         | Cancel one or more instances of an existing      |
   |                | to-do.                                           |
   |                |                                                  |
   | REFRESH        | A request sent to a VTODO Organizer asking for   |
   |                | the latest version of a VTODO.                   |
   |                |                                                  |
   | COUNTER        | Counter a REQUEST with an alternative proposal.  |
   |                |                                                  |
   | DECLINECOUNTER | Decline a counter proposal by an Attendee.       |
   +================+==================================================+

3.4.1 PUBLISH

   The "PUBLISH" method in a "VTODO" calendar component has no
   associated response. It is simply a posting of an iCalendar object
   that maybe added to a calendar. It MUST have an "Organizer".  It MUST
   NOT have "Attendees". Its expected usage is for encapsulating an
   arbitrary "VTODO" calendar component as an iCalendar object. The
   "Organizer" MAY subsequently update (with another "PUBLISH" method),
   add instances to (with an "ADD" method), or cancel (with a "CANCEL"

Silverberg, et. al.         Standards Track                    [Page 35]

RFC 2446                          iTIP                     November 1998

   method) a previously published "VTODO" calendar component.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD               1       MUST be "PUBLISH"
VTODO                1+
    DTSTAMP          1
    DTSTART          1
    ORGANIZER        1
    PRIORITY         1
    SEQUENCE         0 or 1  MUST be present if value is greater than
                             0, MAY be present if 0
    SUMMARY          1       Can be null.
    UID              1

    ATTACH           0+
    CATEGORIES       0 or 1  This property may contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    DESCRIPTION      0 or 1  Can be null
    DUE              0 or 1  If present DURATION MUST NOT be present
    DURATION         0 or 1  If present DUE MUST NOT be present
    EXDATE           0+
    EXRULE           0+
    GEO              0 or 1
    LAST-MODIFIED    0 or 1
    LOCATION         0 or 1
    PERCENT-COMPLETE 0 or 1
    RDATE            0+
    RECURRENCE-ID    0 or 1  MUST only if referring to an instance of a
                             recurring calendar component.  Otherwise
                             it MUST NOT be present.

    RELATED-TO       0+
    RESOURCES        0 or 1  This property may contain a list of values
    RRULE            0+
STATUS           0 or 1  MAY be one of COMPLETED/NEEDS ACTION/IN-
                             PROCESS/CANCELLED
    URL              0 or 1
    X-PROPERTY      0+

    ATTENDEE         0
    REQUEST-STATUS   0

Silverberg, et. al.         Standards Track                    [Page 36]

RFC 2446                          iTIP                     November 1998

VTIMEZONE            0+    MUST be present if any date/time refers to
                           a timezone
VALARM               0+
X-COMPONENT          0+

VFREEBUSY            0
VEVENT               0
VJOURNAL             0

3.4.2 REQUEST

   The "REQUEST" method in a "VTODO" calendar component provides the
   following scheduling functions:

     .  Assign a to-do to one or more "Calendar Users";
     .  Reschedule an existing to-do;
     .  Update the details of an existing to-do, without rescheduling
        it;
     .  Update the completion status of "Attendees" of an existing
        to-do, without rescheduling it;
     .  Reconfirm an existing to-do, without rescheduling it;
     .  Delegate/reassign an existing to-do to another "Calendar User".

   The assigned "Calendar Users" are identified in the "VTODO" calendar
   component by individual "ATTENDEE;ROLE=REQ-PARTICIPANT" property
   value sequences.

   The originator of a "REQUEST" is the "Organizer" of the to-do. The
   recipient of a "REQUEST" is the "Calendar User" assigned the to-do.
   The "Attendee" uses the "REPLY" method to convey their acceptance and
   completion status to the "Organizer" of the "REQUEST".

   The "UID", "SEQUENCE", and "DTSTAMP" properties are used to
   distinguish the various uses of the "REQUEST" method. If the "UID"
   property value in the "REQUEST" is not found on the recipient's
   calendar, then the "REQUEST" is for a new to-do. If the "UID"
   property value is found on the recipient's calendar, then the
   "REQUEST" is a rescheduling, an update, or a reconfirm of the "VTODO"
   calendar object.

   If the "Organizer" of the "REQUEST" method is not authorized to make
   a to-do request on the "Attendee's" calendar system, then an
   exception is returned in the "REQUEST-STATUS" property of a
   subsequent "REPLY" method, but no scheduling action is performed.

   For the "REQUEST" method, multiple "VTODO" components in a single
   iCalendar object are only permitted when for components with the same
   "UID" property.  That is, a series of recurring events may have

Silverberg, et. al.         Standards Track                    [Page 37]

RFC 2446                          iTIP                     November 1998

   instance-specific information.  In this case, multiple "VTODO"
   components are needed to express the entire series.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD                1       MUST be "REQUEST"
VTODO                 1+      All components must have the same UID
    ATTENDEE          1+
    DTSTAMP           1
    DTSTART           1
    ORGANIZER         1
    PRIORITY          1
    SEQUENCE          0 or 1  MUST be present if value is greater than
                              0, MAY be present if 0
    SUMMARY           1       Can be null.
    UID               1

    ATTACH            0+
    CATEGORIES        0 or 1   This property may contain a list of
                               values
    CLASS             0 or 1
    COMMENT           0 or 1
    CONTACT           0+
    CREATED           0 or 1
    DESCRIPTION       0 or 1  Can be null
    DUE               0 or 1  If present DURATION MUST NOT be present
    DURATION          0 or 1  If present DUE MUST NOT be present
    EXDATE            0+
    EXRULE            0+
    GEO               0 or 1
    LAST-MODIFIED     0 or 1
    LOCATION          0 or 1
    PERCENT-COMPLETE  0 or 1
    RDATE             0+
    RECURRENCE-ID     0 or 1  present if referring to an instance of a
                              recurring calendar component.  Otherwise
                              it MUST NOT be present.
    RELATED-TO        0+
    RESOURCES         0 or 1  This property may contain a list of
                              values
    RRULE             0+
    STATUS            0 or 1  MAY be one of COMPLETED/NEEDS ACTION/IN-
                              PROCESS
    URL               0 or 1
    X-PROPERTY        0+

Silverberg, et. al.         Standards Track                    [Page 38]

RFC 2446                          iTIP                     November 1998

    REQUEST-STATUS    0

VALARM                0+

VTIMEZONE             0+  MUST be present if any date/time refers
                          to a timezone
X-COMPONENT           0+

VEVENT                0
VFREEBUSY             0
VJOURNAL              0

3.4.2.1 REQUEST for Rescheduling a VTODO

   The "REQUEST" method may be used to reschedule a "VTODO" calendar
   component.

   Rescheduling a "VTODO" calendar component involves a change to the
   existing "VTODO" calendar component in terms of its start or due time
   or recurrence intervals and possibly the description. If the
   recipient CUA of a "REQUEST" method finds that the "UID" property
   value already exists on the calendar, but that the "SEQUENCE"
   property value in the "REQUEST" is greater than the value for the
   existing VTODO, then the "REQUEST" method describes a rescheduling of
   the "VTODO" calendar component.

3.4.2.2 REQUEST for Update or Reconfirmation of a VTODO

   The "REQUEST" method may be used to update or reconfirm a "VTODO"
   calendar component. Reconfirmation is merely an update of "Attendee"
   completion status or overall "VTODO" calendar component status.

   An update to an existing "VTODO" calendar component does not involve
   changes to the start or due time or recurrence intervals, nor
   generally to the description for the "VTODO" calendar component. If
   the recipient CUA of a "REQUEST" method finds that the "UID" property
   value already exists on the calendar and that the "SEQUENCE" property
   value in the "REQUEST" is the same as the value for the existing
   event, then the "REQUEST" method describes an update of the "VTODO"
   calendar component details, but not a rescheduling of the "VTODO"
   calendar component.

   The update "REQUEST" is the appropriate response to a "REFRESH"
   method sent from an "Attendee" to the "Organizer" of a "VTODO"
   calendar component.

   Unsolicited "REQUEST" methods MAY be sent by the "Organizer" of a
   "VTODO" calendar component. The unsolicited "REQUEST" methods are

Silverberg, et. al.         Standards Track                    [Page 39]

RFC 2446                          iTIP                     November 1998

   used to update the details of the "VTODO" (without rescheduling it or
   updating the completion status of "Attendees") or the "VTODO"
   calendar component itself (i.e., reconfirm the "VTODO").

3.4.2.3 REQUEST for Delegating a VTODO

   The "REQUEST" method is also used to delegate or reassign ownership
   of a "VTODO" calendar component to another "Calendar User". For
   example, it may be used to delegate an "Attendee's" role (i.e.
   "chair", or "participant") for a "VTODO" calendar component. The
   "REQUEST" method is sent by one of the "Attendees" of an existing

   "VTODO" calendar component to some other individual. An "Attendee" of
   a "VTODO" calendar component MUST NOT delegate to the "Organizer" of
   the event.

   For the purposes of this description, the "Attendee" delegating the
   "VTODO" calendar component is referred to as the "Delegator". The
   "Attendee" receiving the delegation request is referred to as the
   "Delegate".

   The "Delegator" of a "VTODO" calendar component MUST forward the
   existing "REQUEST" method for a "VTODO" calendar component to the
   "Delegate". The "VTODO" calendar component description MUST include
   the "Delegator's" up-to-date "VTODO" calendar component definition.
   The "REQUEST" method MUST also include an "ATTENDEE" property with
   the calendar address of the "Delegate". The "Delegator" MUST also
   send a "REPLY" method back to the "Organizer" with the "Delegator's"
   "Attendee" property "partstat" parameter value set to "DELEGATED". In
   addition, the "delegated-to" parameter MUST be included with the
   calendar address of the "Delegate". A response to the delegation
   "REQUEST" is sent from the "Delegate" to the "Organizer" and
   optionally, to the "Delegator". The "REPLY" method from the
   "Delegate" SHOULD include the "ATTENDEE" property with their calendar
   address and the "delegated-from" parameter with the value of the
   "Delegator's" calendar address.

   The delegation "REQUEST" method MUST assign a value for the "RSVP"
   property parameter associated with the "Delegator's" "Attendee"
   property to that of the "Delegate's" "ATTENDEE" property. For example
   if the "Delegator's" "ATTENDEE" property specifies "RSVP=TRUE", then
   the "Delegate's" "ATTENDEE" property MUST specify "RSVP=TRUE".

3.4.2.4 REQUEST Forwarded To An Uninvited Calendar User

   An "Attendee" assigned a "VTODO" calendar component may send the
   "VTODO" calendar component to another new CU, not previously
   associated with the "VTODO" calendar component. The current

Silverberg, et. al.         Standards Track                    [Page 40]

RFC 2446                          iTIP                     November 1998

   "Attendee" assigned the "VTODO" calendar component does this by
   forwarding the original "REQUEST" method to the new CU. The new CU
   can send a "REPLY" to the "Organizer" of the "VTODO" calendar
   component. The reply contains an "ATTENDEE" property for the new CU.

   The "Organizer" ultimately decides whether or not the new CU becomes
   part of the to-do and is not obligated to do anything with a "REPLY"
   from a new (uninvited) CU. If the "Organizer" does not want the new
   CU to be part of the to-do, the new "ATTENDEE" property is not added
   to the "VTODO" calendar component. The "Organizer" MAY send the CU a
   "CANCEL" message to indicate that they will not be added to the to-
   do. If the "Organizer" decides to add the new CU, the new "ATTENDEE"
   property is added to the "VTODO" calendar component. Furthermore, the
   "Organizer" is free to change any "ATTENDEE" property parameter from
   the values supplied by the new CU to something the "Organizer"
   considers appropriate.

3.4.2.5 REQUEST Updated Attendee Status

   An "Organizer" of a "VTODO" may request an updated status from one or
   more "Attendees". The "Organizer" sends a "REQUEST" method to the
   "Attendee" with the "ATTENDEE;RSVP=TRUE" property sequence. The
   "SEQUENCE" property for the "VTODO" is not changed from its previous
   value. A recipient determines that the only change in the "REQUEST"
   is that their "RSVP" property parameter indicates a request for an
   updated status. The recipient SHOULD respond with a "REPLY" method
   indicating their current status with respect to the "REQUEST".

3.4.3 REPLY

   The "REPLY" method in a "VTODO" calendar component is used to respond
   (e.g., accept or decline) to a request or to reply to a delegation
   request. It is also used by an "Attendee" to update their completion
   status. When used to provide a delegation response, the "Delegator"
   MUST include the calendar address of the "Delegate" in the
   "delegated-to" parameter of the "Delegator's" "ATTENDEE" property.
   The "Delegate" MUST include the calendar address of the "Delegator"
   on the "delegated-from" parameter of the "Delegate's" "ATTENDEE"
   property.

   The "REPLY" method MAY also be used to respond to an unsuccessful
   "VTODO" calendar component "REQUEST" method. Depending on the
   "REQUEST-STATUS" value, no scheduling action may have been performed.

   The "Organizer" of a "VTODO" calendar component MAY receive a "REPLY"
   method from a "Calendar User" not in the original "REQUEST". For
   example, a "REPLY" method MAY be received from a "Delegate" of a
   "VTODO" calendar component. In addition, the "REPLY" method MAY be

Silverberg, et. al.         Standards Track                    [Page 41]

RFC 2446                          iTIP                     November 1998

   received from an unknown "Calendar User", having been forwarded the
   "REQUEST" by an original "Attendee" of the "VTODO" calendar
   component. This uninvited "Attendee" MAY be accepted, or the
   "Organizer" MAY cancel the "VTODO" calendar component for the
   uninvited "Attendee" by sending them a "CANCEL" method.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property   Presence
-------------------  ---------------------------------------------
METHOD               1      MUST be "REPLY"
VTODO                1+     All component MUST have the same UID
    ATTENDEE         1+
    DTSTAMP          1
    ORGANIZER        1
    REQUEST-STATUS   1+
    UID              1      MUST must be the address of the replying
                            attendee

    ATTACH           0+
    CATEGORIES       0 or 1 This property may contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    DESCRIPTION      0 or 1
    DTSTART          0 or 1
    DUE              0 or 1  If present DURATION MUST NOT be present
    DURATION         0 or 1  If present DUE MUST NOT be present
    EXDATE           0+
    EXRULE           0+
    GEO              0 or 1
    LAST-MODIFIED    0 or 1
    LOCATION         0 or 1
    PERCENT-COMPLETE 0 or 1
    PRIORITY         0 or 1
    RDATE            0+
    RELATED-TO       0+
    RESOURCES        0 or 1  This property may contain a list of values
    RRULE            0+
    RECURRENCE-ID    0 or 1  MUST only if referring to an instance of a
                             Recurring calendar component. Otherwise it
                             MUST NOT be present
    SEQUENCE         0 or 1  MUST be the sequence number of
                             the original REQUEST if greater than 0.
                             MAY be present if 0.
    STATUS           0 or 1

Silverberg, et. al.         Standards Track                    [Page 42]

RFC 2446                          iTIP                     November 1998

    SUMMARY          0 or 1  Can be null
    URL              0 or 1
    X-PROPERTY       0+

VTIMEZONE            0 or 1  MUST be present if any date/time refers to
                             a timezone
X-COMPONENT          0+

VALARM               0
VEVENT               0
VFREEBUSY            0

3.4.4 ADD

   The "ADD" method in a "VTODO" calendar component is used to add one
   or more instances to an existing to-do.

   If the "UID" property value in the "ADD" is not found on the
   recipient's calendar, then the recipient SHOULD send a "REFRESH" to
   the "Organizer" in order to be updated with the latest version of the
   "VTODO". If an "Attendee" implementation does not support the "ADD"
   method it should respond with a "REQUEST-STATUS" value of 5.3 and ask
   for a "REFRESH".

   The "SEQUENCE" property value is incremented as the sequence of to-
   dos has changed.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD                1       MUST be "ADD"
VTODO                 1
    DTSTAMP           1
    ORGANIZER         1
    PRIORITY          1
    SEQUENCE          1       MUST be greater than 0
    SUMMARY           1       Can be null.
    UID               1       MUST match that of the original to-do

    ATTACH            0+
    ATTENDEE          0+
    CATEGORIES        0 or 1  This property may contain a list of
                              values
    CLASS             0 or 1
    COMMENT           0 or 1
    CONTACT           0+

Silverberg, et. al.         Standards Track                    [Page 43]

RFC 2446                          iTIP                     November 1998

    CREATED           0 or 1
    DESCRIPTION       0 or 1  Can be null
    DTSTART           0 or 1
    DUE               0 or 1  If present DURATION MUST NOT be present
    DURATION          0 or 1  If present DUE MUST NOT be present
    EXDATE            0+
    EXRULE            0+
    GEO               0 or 1
    LAST-MODIFIED     0 or 1
    LOCATION          0 or 1
    PERCENT-COMPLETE  0 or 1
    RDATE             0+
    RELATED-TO        0+
    RESOURCES         0 or 1  This property may contain a list of
                              values
    RRULE             0+
    STATUS            0 or 1  MAY be one of COMPLETED/NEEDS ACTION/IN-
                              PROCESS
    URL               0 or 1
    X-PROPERTY        0+

    RECURRENCE-ID     0
    REQUEST-STATUS    0

VALARM                0+
VTIMEZONE             0+      MUST be present if any date/time refers
                              to a timezone
X-COMPONENT           0+

VEVENT                0
VJOURNAL              0
VFREEBUSY             0

3.4.5 CANCEL

   The "CANCEL" method in a "VTODO" calendar component is used to send a
   cancellation notice of an existing "VTODO" calendar request to the
   "Attendees". The message is sent by the "Organizer" of a "VTODO"
   calendar component to the "Attendees" of the "VTODO" calendar
   component.  For a recurring "VTODO" calendar component, either the
   whole "VTODO" calendar component or instances of a "VTODO" calendar
   component may be cancelled. To cancel the complete range of a
   recurring "VTODO" calendar component, the "UID" property value for
   the "VTODO" calendar component MUST be specified and a "RECURRENCE-
   ID" MUST NOT be specified in the "CANCEL" method. In order to cancel
   an individual instance of a recurring "VTODO" calendar component, the
   "RECURRENCE-ID" property value for the "VTODO" calendar component
   MUST be specified in the "CANCEL" method.

Silverberg, et. al.         Standards Track                    [Page 44]

RFC 2446                          iTIP                     November 1998

   There are two options for canceling a sequence of instances of a
   recurring "VTODO" calendar component:

   (a) the "RECURRENCE-ID" property for an instance in the sequence MUST
       be specified with the "RANGE" property parameter value of
       THISANDPRIOR (or THISANDFUTURE)  to indicate cancellation of the
       specified "VTODO" calendar component and all instances before (or
       after); or

   (b) individual recurrence instances may be cancelled by specifying
       multiple "RECURRENCE-ID" properties corresponding to the
       instances to be cancelled.

   When a "VTODO" is cancelled, the "SEQUENCE" property value MUST be
   incremented.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property   Presence
-------------------  ---------------------------------------------
METHOD               1     MUST be "CANCEL"
VTODO                1
    ATTENDEE         0+    include all "Attendees" being removed from
                           the todo. MUST include all "Attendees" if
                           the entire todo is cancelled.
    UID              1     MUST echo original UID
    DTSTAMP          1
    ORGANIZER        1
    SEQUENCE         1

    ATTACH           0+
    CATEGORIES       0 or 1 This property MAY contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    DESCRIPTION      0 or 1
    DTSTART          0 or 1
    DUE              0 or 1  If present DURATION MUST NOT be present
    DURATION         0 or 1  If present DUE MUST NOT be present
    EXDATE           0+
    EXRULE           0+
    GEO              0 or 1
    LAST-MODIFIED    0 or 1
    LOCATION         0 or 1
    PERCENT-COMPLETE 0 or 1
    RDATE            0+

Silverberg, et. al.         Standards Track                    [Page 45]

RFC 2446                          iTIP                     November 1998

    RECURRENCE-ID    0 or 1 MUST only if referring to one or more
                            instances of a recurring calendar
                            component. Otherwise it MUST NOT be
                            present.
    RELATED-TO       0+
    RESOURCES        0 or 1 This property MAY contain a list of values
    RRULE            0+
    PRIORITY         0 or 1
    STATUS           0 or 1  If present it MUST be set to "CANCELLED".
                             MUST NOT be used if purpose is to remove
                             "ATTENDEES" rather than cancel the entire
                             VTODO.
    URL              0 or 1
    X-PROPERTY       0+

    REQUEST-STATUS   0

VTIMEZONE            0 or 1  MUST be present if any date/time refers to
                             a timezone
X-COMPONENT          0+

VALARM               0
VEVENT               0
VFREEBUSY            0

3.4.6 REFRESH

   The "REFRESH" method in a "VTODO" calendar component is used by
   "Attendees" of an existing "VTODO" calendar component to request an
   updated description from the "Organizer" of the "VTODO" calendar
   component. The "Organizer" of the "VTODO" calendar component MAY use
   this method to request an updated status from the "Attendees". The
   "REFRESH" method MUST specify the "UID" property corresponding to the
   "VTODO" calendar component needing update.

   A refresh of a recurrence instance of a "VTODO" calendar component
   may be requested by specifying the "RECURRENCE-ID" property
   corresponding to the associated "VTODO" calendar component. The
   "Organizer" responds with the latest description and rendition of the
   "VTODO" calendar component.  In most cases this will be a REQUEST
   unless the "VTODO" has been cancelled, in which case the ORGANIZER
   MUST send a "CANCEL". This method is intended to facilitate machine
   processing of requests for updates to a "VTODO" calendar component.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Silverberg, et. al.         Standards Track                    [Page 46]

RFC 2446                          iTIP                     November 1998

Component/Property   Presence
-------------------  ---------------------------------------------
METHOD               1      MUST be "REFRESH"
VTODO                1
    ATTENDEE         1
    DTSTAMP          1
    UID              1       MUST echo original UID

    RECURRENCE-ID    0 or 1  MUST only if referring to an instance of a
                             Recurring calendar component. Otherwise it
                             MUST NOT be present
    X-PROPERTY       0+

    ATTACH           0
    CATEGORIES       0
    CLASS            0
    COMMENT          0
    CONTACT          0
    CREATED          0
    DESCRIPTION      0
    DTSTART          0
    DUE              0
    DURATION         0
    EXDATE           0
    EXRULE           0
    GEO              0
    LAST-MODIFIED    0
    LOCATION         0
    ORGANIZER        0
    PERCENT-COMPLETE 0
    PRIORITY         0
    RDATE            0
    RELATED-TO       0
    REQUEST-STATUS   0
    RESOURCES        0
    RRULE            0
    SEQUENCE         0
    STATUS           0
    URL              0

X-COMPONENT          0+

VALARM               0
VEVENT               0
VFREEBUSY            0
VTIMEZONE            0

Silverberg, et. al.         Standards Track                    [Page 47]

RFC 2446                          iTIP                     November 1998

3.4.7 COUNTER

   The "COUNTER" method in a "VTODO" calendar component is used by an
   "Attendee" of an existing "VTODO" calendar component to submit to the
   "Organizer" a counter proposal for the "VTODO" calendar component.
   The "Attendee" sends the message to the "Organizer" of the "VTODO"
   calendar component.

   The counter proposal is an iCalendar object consisting of a "VTODO"
   calendar component describing the complete description of the
   alternate "VTODO" calendar component.

   The "Organizer" rejects the counter proposal by sending the
   "Attendee" a "DECLINECOUNTER" method. The "Organizer" accepts the
   counter proposal by sending all of the "Attendees" of the "VTODO"
   calendar component a "REQUEST" method rescheduling the "VTODO"
   calendar component. In the latter case, the "Organizer" SHOULD reset
   the individual "RSVP" property parameter values to TRUE on each
   "ATTENDEE" property; in order to force a response by the "Attendees".

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD               1      MUST be "COUNTER"
VTODO                1
    ATTENDEE         1+
    DTSTAMP          1
    ORGANIZER        1
    PRIORITY         1
    SUMMARY          1      Can be null
    UID              1

    ATTACH           0+
    CATEGORIES       0 or 1 This property MAY contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    DESCRIPTION      0 or 1 Can be null
    DTSTART          0 or 1
    DUE              0 or 1  If present DURATION MUST NOT be present
    DURATION         0 or 1  If present DUE MUST NOT be present
    EXDATE           0+
    EXRULE           0+
    GEO              0 or 1
    LAST-MODIFIED    0 or 1

Silverberg, et. al.         Standards Track                    [Page 48]

RFC 2446                          iTIP                     November 1998

    LOCATION         0 or 1
    PERCENT-COMPLETE 0 or 1
    RDATE            0+
    RECURRENCE-ID    0 or 1 MUST only 3.5if referring to an instance of a
                            recurring calendar component.  Otherwise it
                            MUST NOT be present.
    RELATED-TO       0+
    REQUEST-STATUS   0+
    RESOURCES        0 or 1 This property MAY contain a list of values
    RRULE            0 or 1
    SEQUENCE         0 or 1 MUST echo the original SEQUENCE number.
                            MUST be present if non-zero. MAY be present
                            if zero.
    STATUS           0 or 1 MAY be one of COMPLETED/NEEDS ACTION/IN-
                            PROCESS/CANCELLED
    URL              0 or 1
    X-PROPERTY       0+

VALARM               0+
VTIMEZONE            0 or 1  MUST be present if any date/time refers to
                             a timezone
X-COMPONENT          0+

VEVENT               0
VFREEBUSY            0

3.4.8 DECLINECOUNTER

   The "DECLINECOUNTER" method in a "VTODO" calendar component is used
   by an "Organizer" of "VTODO" calendar component to reject a counter
   proposal offered by one of the "Attendees". The "Organizer" sends the
   message to the "Attendee" that sent the "COUNTER" method to the
   "Organizer".

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property   Presence
-------------------  ---------------------------------------------
METHOD               1       MUST be "DECLINECOUNTER"

VTODO                1
    ATTENDEE         1+      MUST for all attendees
    DTSTAMP          1
    ORGANIZER        1
    SEQUENCE         1       MUST echo the original SEQUENCE number
    UID              1       MUST echo original UID

Silverberg, et. al.         Standards Track                    [Page 49]

RFC 2446                          iTIP                     November 1998

    ATTACH           0+
    CATEGORIES       0 or 1  This property may contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    DESCRIPTION      0 or 1
    DTSTART          0 or 1
    DUE              0 or 1  If present DURATION MUST NOT be present
    DURATION         0 or 1  If present DUE MUST NOT be present
    EXDATE           0+
    EXRULE           0+
    GEO              0 or 1
    LAST-MODIFIED    0 or 1
    LOCATION         0 or 1
    PERCENT-COMPLETE 0 or 1
    PRIORITY         0 or 1
    RDATE            0+
    RECURRENCE-ID    0 or 1  MUST only if referring to an instance of a
                             recurring calendar component.  Otherwise
                             it MUST NOT be present.
    RELATED-TO       0+
    REQUEST-STATUS   0+
    RESOURCES        0 or 1  This property MAY contain a list of values
    RRULE            0+
    STATUS           0 or 1  MAY be one of COMPLETED/NEEDS ACTION/IN-
                             PROCESS
    URL              0 or 1
    X-PROPERTY       0+

VTIMEZONE            0+  MUST be present if any date/time refers to
                         a timezone
X-COMPONENT          0+

VALARM               0
VEVENT               0
VFREEBUSY            0

3.5 Methods For VJOURNAL Components

   This section defines the property set for the methods that are
   applicable to the "VJOURNAL" calendar component.

   The following summarizes the methods that are defined for the
   "VJOURNAL" calendar component.

Silverberg, et. al.         Standards Track                    [Page 50]

RFC 2446                          iTIP                     November 1998

   +================+==================================================+
   | Method         |  Description                                     |
   |================+==================================================|
   | PUBLISH        | Post a journal entry. Used primarily as a method |
   |                | of advertising the existence of a journal entry. |
   |                |                                                  |
   | ADD            | Add one or more instances to an existing journal |
   |                | entry.                                           |
   |                |                                                  |
   | CANCEL         | Cancel one or more instances of an existing      |
   |                | journal entry.                                   |
   +================+==================================================+

3.5.1 PUBLISH

   The "PUBLISH" method in a "VJOURNAL" calendar component has no
   associated response. It is simply a posting of an iCalendar object
   that may be added to a calendar. It MUST have an "Organizer". It MUST
   NOT have "Attendees". The expected usage is for encapsulating an

   arbitrary journal entry as an iCalendar object. The "Organizer" MAY
   subsequently update (with another "PUBLISH" method) or cancel (with a
   "CANCEL" method) a previously published journal entry.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD               1       MUST be "PUBLISH"
VJOURNAL             1+
    DESCRIPTION      1       Can be null.
    DTSTAMP          1
    DTSTART          1
    ORGANIZER        1
    UID              1

    ATTACH           0+
    CATEGORIES       0 or 1  This property MAY contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    EXDATE           0+
    EXRULE           0+
    LAST-MODIFIED    0 or 1
    RDATE            0+
    RECURRENCE-ID    0 or 1  MUST only if referring to an instance of a

Silverberg, et. al.         Standards Track                    [Page 51]

RFC 2446                          iTIP                     November 1998

                             recurring calendar component.  Otherwise
                             it MUST NOT be present.
    RELATED-TO       0+
    RRULE            0+
    SEQUENCE         0 or 1  MUST echo the original SEQUENCE number.
                             MUST be present if non-zero. MAY be
                             present if zero.
    STATUS           0 or 1  MAY be one of DRAFT/FINAL/CANCELLED
    SUMMARY          0 or 1  Can be null
    URL              0 or 1
    X-PROPERTY       0+

    ATTENDEE         0

VALARM               0+
VTIMEZONE            0+      MUST be present if any date/time refers to
                             a timezone
X-COMPONENT          0+

VEVENT               0
VFREEBUSY            0
VTODO                0

3.5.2 ADD

   The "ADD" method in a "VJOURNAL" calendar component is used to add
   one or more instances to an existing "VJOURNAL" entry. There is no
   response to the "Organizer".

   If the "UID" property value in the "ADD" is not found on the
   recipient's calendar, then the recipient MAY treat the "ADD" as a
   "PUBLISH".

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property  Presence
------------------- ----------------------------------------------
METHOD               1      MUST be "ADD"
VJOURNAL             1
    DESCRIPTION      1      Can be null.
    DTSTAMP          1
    DTSTART          1
    ORGANIZER        1
    SEQUENCE         1      MUST be greater than 0
    UID              1      MUST match that of the original journal

    ATTACH           0+

Silverberg, et. al.         Standards Track                    [Page 52]

RFC 2446                          iTIP                     November 1998

    CATEGORIES       0 or 1 This property MAY contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    EXDATE           0+
    EXRULE           0+
    LAST-MODIFIED    0 or 1
    RDATE            0+
    RELATED-TO       0+
    RRULE            0+
    STATUS           0 or 1  MAY be one of DRAFT/FINAL/CANCELLED
    SUMMARY          0 or 1  Can be null
    URL              0 or 1
    X-PROPERTY       0+

    ATTENDEE         0
    RECURRENCE-ID    0

VALARM               0+
VTIMEZONE            0 or 1 MUST be present if any date/time refers to
                            a timezone
X-COMPONENT          0+

VEVENT               0
VFREEBUSY            0
VTODO                0

3.5.3 CANCEL

   The "CANCEL" method in a "VJOURNAL" calendar component is used to
   send a cancellation notice of an existing journal entry. The message
   is sent by the "Organizer" of a journal entry. For a recurring
   journal entry, either the whole journal entry or instances of a
   journal entry may be cancelled. To cancel the complete range of a
   recurring journal entry, the "UID" property value for the journal
   entry MUST be specified and a "RECURRENCE-ID" property MUST NOT be
   specified in the "CANCEL" method.  In order to cancel an individual
   instance of the journal entry, the "RECURRENCE-ID" property value for
   the journal entry MUST be specified in the "CANCEL" method.

   There are two options for canceling a sequence of instances of a
   recurring "VJOURNAL" calendar component:

Silverberg, et. al.         Standards Track                    [Page 53]

RFC 2446                          iTIP                     November 1998

   (a) the "RECURRENCE-ID" property for an instance in the sequence MUST
       be specified with the "RANGE" property parameter value of
       THISANDPRIOR (or THISANDFUTURE)  to indicate cancellation of the
       specified "VTODO" calendar component and all instances before (or
       after); or

   (b) individual recurrence instances may be cancelled by specifying
       multiple "RECURRENCE-ID" properties corresponding to the
       instances to be cancelled.

   When a "VJOURNAL" is cancelled, the "SEQUENCE" property value MUST be
   incremented.

   This method type is an iCalendar object that conforms to the
   following property constraints:

Component/Property   Presence
-------------------  ---------------------------------------------
METHOD               1       MUST be "CANCEL"
VJOURNAL             1+      All MUST have the same UID
    DTSTAMP          1
    ORGANIZER        1
    SEQUENCE         1
    UID              1       MUST be the UID of the original REQUEST

    ATTACH           0+
    ATTENDEE         0+
    CATEGORIES       0 or 1  This property MAY contain a list of values
    CLASS            0 or 1
    COMMENT          0 or 1
    CONTACT          0+
    CREATED          0 or 1
    DESCRIPTION      0 or 1
    DTSTART          0 or 1
    EXDATE           0+
    EXRULE           0+
    LAST-MODIFIED    0 or 1
    RDATE            0+
    RECURRENCE-ID    0 or 1  only if referring to an instance of a
                             recurring calendar component.  Otherwise
                             it MUST NOT be present.
    RELATED-TO       0+
    RRULE            0+
    STATUS           0 or 1  MAY be present, must be "CANCELLED" if
                             present
    SUMMARY          0 or 1
    URL              0 or 1
    X-PROPERTY       0+

Silverberg, et. al.         Standards Track                    [Page 54]

RFC 2446                          iTIP                     November 1998

    REQUEST-STATUS   0

VTIMEZONE            0+      MUST be present if any date/time refers to
                             a timezone
X-COMPONENT          0+
VALARM               0
VEVENT               0
VFREEBUSY            0
VTODO                0

3.6 Status Replies

   The "REQUEST-STATUS" property may include the following values:

|==============+============================+=========================|
| Short Return | Longer Return Status       | Offending Data          |
| Status Code  | Description                |                         |
|==============+============================+=========================|
| 2.0          | Success.                   | None.                   |
|==============+============================+=========================|
| 2.1          | Success but fallback taken | Property name and value |
|              | on one or more property    | MAY be specified.       |
|              | values.                    |                         |
|==============+============================+=========================|
| 2.2          | Success, invalid property  | Property name MAY be    |
|              | ignored.                   | specified.              |
|==============+============================+=========================|
| 2.3          | Success, invalid property  | Property parameter name |
|              | parameter ignored.         | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 2.4          | Success, unknown non-      | Non-standard property   |
|              | standard property ignored. | name MAY be specified.  |
|==============+============================+=========================|
| 2.5          | Success, unknown non       | Property and non-       |
|              | standard property value    | standard value MAY be   |
|              | ignored.                   | specified.              |
|==============+============================+=========================|
| 2.6          | Success, invalid calendar  | Calendar component      |
|              | component ignored.         | sentinel (e.g., BEGIN:  |
|              |                            | ALARM) MAY be           |
|              |                            | specified.              |
|==============+============================+=========================|
| 2.7          | Success, request forwarded | Original and forwarded  |
|              | to Calendar User.          | caluser addresses MAY   |
|              |                            | be specified.           |
|==============+============================+=========================|
| 2.8          | Success, repeating event   | RRULE or RDATE property |

Silverberg, et. al.         Standards Track                    [Page 55]

RFC 2446                          iTIP                     November 1998

|              | ignored. Scheduled as a    | name and value MAY be   |
|              | single component.          | specified.              |
|==============+============================+=========================|
| 2.9          | Success, truncated end date| DTEND property value    |
|              | time to date boundary.     | MAY be specified.       |
|==============+============================+=========================|
| 2.10         | Success, repeating VTODO   | RRULE or RDATE property |
|              | ignored. Scheduled as a    | name and value MAY be   |
|              | single VTODO.              | specified.              |
|==============+============================+=========================|
| 2.11         | Success, unbounded RRULE   | RRULE property name and |
|              | clipped at some finite     | value MAY be specified. |
|              | number of instances        | Number of instances MAY |
|              |                            | also be specified.      |
|==============+============================+=========================|
| 3.0          | Invalid property name.     | Property name MAY be    |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.1          | Invalid property value.    | Property name and value |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 3.2          | Invalid property parameter.| Property parameter name |
|              |                            | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.3          | Invalid property parameter | Property parameter name |
|              | value.                     | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.4          | Invalid calendar component | Calendar component      |
|              | sequence.                  | sentinel MAY be         |
|              |                            | specified (e.g., BEGIN: |
|              |                            | VTIMEZONE).             |
|==============+============================+=========================|
| 3.5          | Invalid date or time.      | Date/time value(s) MAY  |
|              |                            | be specified.           |
|==============+============================+=========================|
| 3.6          | Invalid rule.              | Rule value MAY be       |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.7          | Invalid Calendar User.     | Attendee property value |
|              |                            |MAY be specified.        |
|==============+============================+=========================|
| 3.8          | No authority.              | METHOD and Attendee     |
|              |                            | property values MAY be  |
|              |                            | specified.              |
|==============+============================+=========================|

Silverberg, et. al.         Standards Track                    [Page 56]

RFC 2446                          iTIP                     November 1998

| 3.9          | Unsupported version.       | VERSION property name   |
|              |                            | and value MAY be        |
|              |                            | specified.              |
|==============+============================+=========================|
| 3.10         | Request entity too large.  | None.                   |
|==============+============================+=========================|
| 3.11         | Required component or      | Component or property   |
|              | property missing.          | name MAY be specified.  |
|==============+============================+=========================|
| 3.12         | Unknown component or       | Component or property   |
|              | property found             | name MAY be specified   |
|==============+============================+=========================|
| 3.13         | Unsupported component or   | Component or property   |
|              | property found             | name MAY be specified   |
|==============+============================+=========================|
| 3.14         | Unsupported capability     | Method or action MAY    |
|              |                            | be specified            |
|==============+============================+=========================|
| 4.0          | Event conflict. Date/time  | DTSTART and DTEND       |
|              | is busy.                   | property name and values|
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.0          | Request MAY supported.     | Method property value   |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.1          | Service unavailable.       | ATTENDEE property value |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.2          | Invalid calendar service.  | ATTENDEE property value |
|              |                            | MAY be specified.       |
|==============+============================+=========================|
| 5.3          | No scheduling support for  | ATTENDEE property value |
|              | user.                      | MAY be specified.       |
|==============+============================+=========================|

3.7 Implementation Considerations

3.7.1 Working With Recurrence Instances

   iCalendar includes a recurrence grammar to represent recurring
   events.  The benefit of such a grammar is the ability to represent a
   number of events in a single object. However, while this simplifies
   creation of a recurring event, meeting instances still need to be
   referenced. For instance, an "Attendee" may decline the third
   instance of a recurring Friday event. Similarly, the "Organizer" may
   change the time or location to a single instance of the recurring
   event.

Silverberg, et. al.         Standards Track                    [Page 57]

RFC 2446                          iTIP                     November 1998

   Since implementations may elect to store recurring events as either a
   single event object or a collection of discreet, related event
   objects, the protocol is designed so that each recurring instance may
   be both referenced and versioned. Hence, implementations that choose
   to maintain per-instance properties (such as "ATTENDEE" property
   "partstat" parameter) may do so. However, the protocol does not
   require per-instance recognition unless the instance itself must be
   renegotiated.

   The scenarios for recurrence instance referencing are listed below.
   For purposes of simplification a change to an event refers to a
   "trigger property."  That is, a property that has a substantive
   effect on the meeting itself such as start time, location, due date
   (for "VTODO" calendar component components) and possibly description.

   "Organizer" initiated actions:

     .  "Organizer" deletes or changes a single instance of a recurring
        event
     .  "Organizer" makes changes that affect all future instances
     .  "Organizer" makes changes that affect all previous instances
     .  "Organizer" deletes or modifies a previously changed instance

   "Attendee" initiated actions:

     .  "Attendee" changes status for a particular recurrence instance
     .  "Attendee" sends Event-Counter for a particular recurrence
        instance

   An instance of a recurring event is assigned a unique identification,
   "RECURRENCE-ID" property, when that instance is renegotiated.
   Negotiation may be necessary when a substantive change to the event
   or to-do has be made (such as changing the start time, end time, due
   date or location). The "Organizer" can identify a specific recurrence
   instance using the "RECURRENCE-ID" property. The property value is
   equal to the date/time of the instance. If the "Organizer" wishes to
   change the "DTSTART", the original "DTSTART" value is used for
   "RECURRENCE-ID" property and the new "DTSTART" and "DTEND" values
   reflect the change.  Note that after the change has occurred, the
   "RECURRENCE-ID" has changed to the new "DTSTART" value.

3.7.2 Attendee Property Considerations

   The "ORGANIZER" property is required on published events, to-dos, and
   journal entries for two reasons. First, only the "Organizer" is
   allowed to update and redistribute an event or to-do component. It
   follows that the "ORGANIZER" property MUST be present in the event,
   to-do, or journal entry component so that the CUA has a basis for

Silverberg, et. al.         Standards Track                    [Page 58]

RFC 2446                          iTIP                     November 1998

   authorizing an update.  Second, it is prudent to provide a point of
   contact for anyone who receives a published component in case of
   problems.

   There are valid [RFC-822] addresses that represent groups. Sending
   email to such an address results in mail being sent to multiple
   recipients.  Such an address may be used as the value of an
   "ATTENDEE" property.  Thus, it is possible that the recipient of a
   "REQUEST" does not appear explicitly in the list.

   It is recommended that the general approach to finding a "Calendar
   User" in an attendee list be as follows:

   1.  Search for the "Calendar User" in the attendee list where
       "TYPE=INDIVIDUAL"

   2.  Failing (1) look for attendees where "TYPE=GROUP" or
       'TYPE=UNKNOWN".  The CUA then determines if the "Calendar User"
       is a member of one of these groups. If so, the "REPLY" method
       sent to the "Organizer" MUST contain a new "ATTENDEE" property in
       which:
         .  the "type" property parameter is set to INDIVIDUAL
         .  the "member" property parameter is set to the name of the
            group

   3.  Failing (2) the CUA MAY ignore or accept the request as the
       "Calendar User" wishes.

3.7.3 X-Tokens

   To make iCalendar objects extensible, new property types MAY be
   inserted into components. These properties are called X-Tokens as
   they are prefixed with "X-". A client is not required to make sense
   of X-Tokens.  Clients are not required to save X-Tokens or use them
   in replies.

4 Examples

4.1 Published Event Examples

   In the calendaring and scheduling context, publication refers to the
   one way transfer of event information. Consumers of published events
   simply incorporate the event into a calendar. No reply is expected.
   Individual "A" publishes an event. Individual "B" reads the event and
   incorporates it into their calendar. Events are published in several
   ways including: embedding the event as an object in a web page, e-
   mailing the event to a distribution list, and posting the event to a
   newsgroup.

Silverberg, et. al.         Standards Track                    [Page 59]

RFC 2446                          iTIP                     November 1998

   The table below illustrates the sequence of events between the
   publisher and the consumers of a published event.

   +-------------------------------------------------------------------+
   | Action                          |  "Organizer"                    |
   +---------------------------------+---------------------------------+
   | Publish an event                | "A" sends or posts a PUBLISH    |
   |                                 | message                         |
   +---------------------------------+---------------------------------+
   | "B" reads a published event     |                                 |
   +---------------------------------+---------------------------------+
   | Publish an updated event        | "A" sends or posts a PUBLISH    |
   |                                 | message                         |
   +---------------------------------+---------------------------------+
   | "B" reads the updated event     |                                 |
   +---------------------------------+---------------------------------+
   | Cancel a published event        | "A" sends or posts a CANCEL     |
   |                                 | message                         |
   +---------------------------------+---------------------------------+
   | "B" reads the canceled event    |                                 |
   |  publication                    |                                 |
   +---------------------------------+---------------------------------+

4.1.1 A Minimal Published Event

   The iCalendar object below describes a single event that begins on
   July 1, 1997 at 20:00 UTC. This event contains the minimum set of
   properties for a "PUBLISH" for a "VEVENT" calendar component.

   BEGIN:VCALENDAR
   METHOD:PUBLISH
   PRODID:-//ACME/DesktopCalendar//EN
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:a@example.com
   DTSTART:19970701T200000Z
   DTSTAMP:19970611T190000Z
   SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
   UID:0981234-1234234-23@example.com
   END:VEVENT
   END:VCALENDAR

4.1.2 Changing A Published Event

   The iCalendar object below describes an update to the event described
   in 4.1.1, the time has been changed, an end time has been added, and
   the sequence number has been adjusted.

Silverberg, et. al.         Standards Track                    [Page 60]

RFC 2446                          iTIP                     November 1998

   BEGIN:VCALENDAR
   METHOD:PUBLISH
   VERSION:2.0
   PRODID:-//ACME/DesktopCalendar//EN
   BEGIN:VEVENT
   ORGANIZER:mailto:a@example.com
   DTSTAMP:19970612T190000Z
   DTSTART:19970701T210000Z
   DTEND:19970701T230000Z
   SEQUENCE:1
   UID:0981234-1234234-23@example.com
   SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
   END:VEVENT
   END:VCALENDAR

   The "UID" property is used by the client to identify the event. The
   "SEQUENCE" property indicates that this is a change to the event. The
   event with a matching UID and sequence number 0 is superseded by this
   event.

   The "SEQUENCE" property provides a reliable way to distinguish
   different versions of the same event. Each time an event is
   published, its sequence number is incremented. If a client receives
   an event with a sequence number 5 and finds it has the same event
   with sequence number 2, the event SHOULD be updated. However, if the
   client received an event with sequence number 2 and finds it already
   has sequence number 5 of the same event, the event MUST NOT be
   updated.

4.1.3 Canceling A Published Event

   The iCalendar object below cancels the event described in 4.1.1. This
   cancels the event with "SEQUENCE" property of 0, 1, and 2.

   BEGIN:VCALENDAR
   METHOD:CANCEL
   VERSION:2.0
   PRODID:-//ACME/DesktopCalendar//EN
   BEGIN:VEVENT
   ORGANIZER:mailto:a@example.com
   COMMENT:DUKES forfeit the game
   SEQUENCE:2
   UID:0981234-1234234-23@example.com
   DTSTAMP:19970613T190000Z
   END:VEVENT
   END:VCALENDAR

Silverberg, et. al.         Standards Track                    [Page 61]

RFC 2446                          iTIP                     November 1998

4.1.4 A Rich Published Event

   This example describes the same event as in 4.1.1, but in much
   greater detail.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:PUBLISH
   SCALE:GREGORIAN
   VERSION:2.0
   BEGIN:VTIMEZONE
   TZID:America-Chicago
   TZURL:http://zones.stds_r_us.net/tz/America-Chicago
   BEGIN:STANDARD
   DTSTART:19671029T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZOFFSETFROM:-0500
   TZOFFSETTO:-0600
   TZNAME:CST
   END:STANDARD
   BEGIN:DAYLIGHT
   DTSTART:19870405T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZOFFSETFROM:-0600
   TZOFFSETTO:-0500
   TZNAME:CDT
   END:DAYLIGHT
   END:VTIMEZONE
   BEGIN:VEVENT
   ORGANIZER:mailto:a@example.com
   ATTACH:http://www.dukes.com/
   CATEGORIES:SPORTS EVENT,ENTERTAINMENT
   CLASS:PRIVATE
   DESCRIPTION:MIDWAY STADIUM\n
    Big time game. MUST see.\n
    Expected duration:2 hours\n
   DTEND;TZID=America-Chicago:19970701T180000
   DTSTART;TZID=America-Chicago:19970702T160000
   DTSTAMP:19970614T190000Z
   STATUS:CONFIRMED
   LOCATION;VALUE=URI:http://www.midwaystadium.com/
   PRIORITY:2
   RESOURCES:SCOREBOARD
   SEQUENCE:3
   SUMMARY:ST. PAUL SAINTS -VS- DULUTH-SUPERIOR DUKES
   UID:0981234-1234234-23@example.com
   RELATED-TO:0981234-1234234-14@example.com
   BEGIN:VALARM

Silverberg, et. al.         Standards Track                    [Page 62]

RFC 2446                          iTIP                     November 1998

   TRIGGER:-PT2H
   ACTION:DISPLAY
   DESCRIPTION:You should be leaving for the game now.
   END:VALARM
   BEGIN:VALARM
   TRIGGER:-PT30M
   ACTION:AUDIO
   END:VALARM
   END:VEVENT
   END:VCALENDAR

   The "RELATED-TO" field contains the "UID" property of a related
   calendar event. The "SEQUENCE" property 3 indicates that this event
   supersedes versions 0, 1, and 2.

4.1.5 Anniversaries or Events attached to entire days

   This example demonstrates the use of the "value" parameter to tie a
   "VEVENT" to day rather than a specific time.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:PUBLISH
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:a@example.com
   DTSTAMP:19970614T190000Z
   UID:0981234-1234234-23@example.com
   DTSTART;VALUE=DATE:19970714
   RRULE:FREQ=YEARLY;INTERVAL=1
   SUMMARY: Bastille Day
   END:VEVENT
   END:VCALENDAR

4.2 Group Event Examples

   Group events are distinguished from published events in that they
   have "Attendees" and that there is interaction between the
   "Attendees" and the "Organizer" with respect to the event. Individual
   "A" requests a meeting between individuals "A", "B", "C" and "D".
   Individual "B" confirms attendance to the meeting. Individual "C"
   declines attendance.  Individual "D" tentatively confirms attendance.
   The following table illustrates the the message flow between these
   individuals. A, the CU scheduling the meeting, is referenced as the
   "Organizer".

Silverberg, et. al.         Standards Track                    [Page 63]

RFC 2446                          iTIP                     November 1998

+---------------------------------------------------------------------+
| Action             |  "Organizer"        | Attendee                 |
+---------------------------------------------------------------------+
| Initiate a meeting | "A" sends a REQUEST |                          |
| request            | message to "B", "C",|                          |
|                    | and "D"             |                          |
+---------------------------------------------------------------------+
| Accept the meeting |                     | "B" sends a REPLY        |
| request            |                     | message to "A" with its  |
|                    |                     | ATTENDEE "partstat" para-|
|                    |                     | set to "accepted"        |
+---------------------------------------------------------------------+
| Decline the meeting|                     | "C" sends a REPLY        |
| request            |                     | message to "A" with its  |
|                    |                     | ATTENDEE "partstat" para-|
|                    |                     | set to "declined"        |
+---------------------------------------------------------------------+
| Tentatively accept |                     | "D" sends a REPLY        |
| the meeting request|                     | message to "A" with its  |
|                    |                     | ATTENDEE "partstat" para-|
|                    |                     | set to "tentative"       |
+---------------------------------------------------------------------+
| Confirm meeting    | "A" sends a REQUEST |                          |
| status with        | message to "B" and  |                          |
| attendees          | "D" with updated    |                          |
|                    | information.        |                          |
+---------------------------------------------------------------------+

4.2.1 A Group Event Request

   A sample meeting request is sent from "A" to "B", "C", and "D". _E_
   is also sent a copy of the request but is not expected to attend and
   need not reply. "E" illustrates how CUAs might implement an "FYI"
   type feature. Note the use of the "role" parameter. The default value
   for the "role" parameter is "req-participant" and it need not be
   enumerated. In this case we are using the value "non-participant" to
   indicate "E" is a non-attending CU. The parameter is not needed on
   other "Attendees" since "participant" is the default value.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;CN=BIG A:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=B:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=C:Mailto:C@example.com

Silverberg, et. al.         Standards Track                    [Page 64]

RFC 2446                          iTIP                     November 1998

   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
   ATTENDEE;RSVP=FALSE;TYPE=ROOM:conf_Big@example.com
   ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T200000Z
   DTEND:19970701T2000000Z
   SUMMARY:Conference
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.2.2 Reply To A Group Event Request

   Attendee "B" accepts the meeting.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VEVENT
   ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com
   ORGANIZER:MAILTO:A@example.com
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   REQUEST-STATUS:2.0;Success
   DTSTAMP:19970612T190000Z
   END:VEVENT
   END:VCALENDAR

   "B" could have declined the meeting or indicated tentative acceptance
   by setting the "ATTENDEE" "partstat" parameter to "declined" or
   "tentative", respectively. Also, "REQUEST-STATUS" is not required in
   successful transactions.

4.2.3 Update An Event

   The event is moved to a different time. The combination of the "UID"
   property (unchanged) and the "SEQUENCE" (bumped to 1) properties
   indicate the update.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com

Silverberg, et. al.         Standards Track                    [Page 65]

RFC 2446                          iTIP                     November 1998

   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL;CN=Hal:Mailto:D@example.com
   ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE;
    CUTYPE=ROOM:Mailto:Conf@example.com
   ATTENDEE;ROLE=NON-PARTICIPANT;RSVP=FALSE:Mailto:E@example.com
   DTSTART:19970701T180000Z
   DTEND:19970701T190000Z
   SUMMARY:Phone Conference
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:1
   DTSTAMP:19970613T190000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.2.4 Countering an Event Proposal

   "A" sends a "REQUEST" to "B" and "C". "B" makes a counter-proposal to
   "A" to change the time and location.

   "A" sends the following "REQUEST":

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
   DTSTART:19970701T190000Z
   DTEND:19970701T200000Z
   SUMMARY:Discuss the Merits of the election results
   LOCATION:Green Conference Room
   UID:calsrv.example.com-873970198738777a@example.com
   SEQUENCE:0
   DTSTAMP:19970611T190000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   "B" sends "COUNTER" to "A", requesting changes to time and place. "B"
   uses the "COMMENT" property to communicate a rationale for the
   change.  Note that the "SEQUENCE" property is NOT incremented on a
   "COUNTER".

Silverberg, et. al.         Standards Track                    [Page 66]

RFC 2446                          iTIP                     November 1998

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:COUNTER
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
   DTSTART:19970701T160000Z
   DTEND:19970701T190000Z
   DTSTAMP:19970612T190000Z
   SUMMARY:Discuss the Merits of the election results
   LOCATION:Green Conference Room
   COMMENT:This time works much better and I think the big conference
     room is too big
   UID:calsrv.example.com-873970198738777a@example.com
   SEQUENCE:0
   DTSTAMP:19970611T190000Z
   END:VEVENT
   END:VCALENDAR

   "A" accepts the changes from "B". To accept a counter-proposal, the
   "Organizer" sends a new event "REQUEST" with an incremented sequence
   number.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:C@example.com
   DTSTAMP:19970613T190000Z
   DTSTART:19970701T160000Z
   DTEND:19970701T190000Z
   SUMMARY:Discuss the Merits of the election results - changed to
     meet B's schedule
   LOCATION:Green Conference Room
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:1
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   Instead, "A" rejects "B's" counter proposal

Silverberg, et. al.         Standards Track                    [Page 67]

RFC 2446                          iTIP                     November 1998

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:DECLINECOUNTER
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   COMMENT:Sorry, I cannot change this meeting time
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   DTSTAMP:19970614T190000Z
   END:VEVENT
   END:VCALENDAR

4.2.5 Delegating an Event

   When delegating an event request to another "Calendar User", the
   "Delegator" must both update the "Organizer" with a "REPLY" and send
   a request to the "Delegate". There is currently no protocol
   limitation to delegation depth. It is possible for the original

   delegate to delegate the meeting to someone else, and so on. When a
   request is delegated from one CUA to another there are a number of
   responsibilities required of the "Delegator". The "Delegator" MUST:

     .  Send a "REPLY" to the "Organizer" with the following updates:
     .  The "Delegator's" "ATTENDEE" property "partstat" parameter set
        to "delegated" and the "delegated-to" parameter is set to the
        address of the "Delegate"
     .  Add an additional "ATTENDEE" property for the "Delegate" with
        the "delegated-from" property parameter set to the "Delegator"
     .  Indicate whether they want to continue to receive updates when
        the "Organizer" sends out updated versions of the event.
        Setting the "rsvp" property parameter to "TRUE" will cause the
        updates to be sent, setting it to "FALSE" causes no further
        updates to be sent. Note that in either case, if the "Delegate"
        declines the invitation the "Delegator" will be notified.
     .  The "Delegator" MUST also send a copy of the original "REQUEST"
        method to the "Delegate".

   It is not required that the "Delegate" include the "Delegator" in
   their "REPLY" method. However, it is strongly advised since this will
   inform the "Delegator" whether the "Delegate" plans to attend the
   meeting.  [Editors note:  How so?] If the "Delegate" declines the
   meeting, the "Delegator" may elect to delegate the "REQUEST" to
   another CUA. The process is the same.

Silverberg, et. al.         Standards Track                    [Page 68]

RFC 2446                          iTIP                     November 1998

+---------------------------------------------------------------------+
| Action             |  "Organizer"        | Attendee                 |
+---------------------------------------------------------------------+
| Initiate a meeting | "A" sends a REQUEST |                          |
| request            | message to "B" and  |                          |
|                    | "C"                 |                          |
+---------------------------------------------------------------------+
| Delegate:          |                     | "C" sends a REPLY to "A" |
| "C" delegates to   |                     | with the ATTENDEE.       |
| "E"                |                     | "partstat" parameter set |
|                    |                     | to "delegated" and with a|
|                    |                     | new "ATTENDEE" property  |
|                    |                     | for "E". "E's" ATTENDEE  |
|                    |                     | "delegated-from" param   |
|                    |                     | is set to "C". "C's"     |
|                    |                     | ATTENDEE "delegated-to"  |
|                    |                     | param is set to "E".     |
|                    |                     | "C" sends REQUEST message|
|                    |                     | to "E" with the original |
|                    |                     | meeting request          |
|                    |                     | information. The         |
|                    |                     |  "partstat" property     |
|                    |                     | parameter for "C" is set |
|                    |                     | to "delegated" and the   |
|                    |                     |  "delegated-to"          |
|                    |                     | parameter is set to      |
|                    |                     | the address of "E". An   |
|                    |                     | "ATTENDEE" property is   |
|                    |                     | added for "E" and the    |
|                    |                     | "delegated-from"         |
|                    |                     | parameter is set to      |
|                    |                     | the address of "C".      |
+---------------------------------------------------------------------+
| Confirm meeting    |                     | "E" sends REPLY message  |
| attendance         |                     | to "A" and optionally "C"|
|                    |                     | with its "partstat"      |
|                    |                     | property parameter set   |
|                    |                     | to "ACCEPTED"            |
+---------------------------------------------------------------------+
| Optional:          | "A" sends REQUEST   |                          |
| Redistribute       | message to "B", "C" |                          |
| meeting to         | and "E".            |                          |
| attendees          |                     |                          |
+---------------------------------------------------------------------+

Silverberg, et. al.         Standards Track                    [Page 69]

RFC 2446                          iTIP                     November 1998

   "C" responds to the "Organizer".

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:MAILTO:A@Example.com
   ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
    TO="Mailto:E@example.com":Mailto:C@example.com
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   REQUEST-STATUS:2.0;Success
   DTSTAMP:19970611T190000Z
   END:VEVENT
   END:VCALENDAR

   Attendee "C" delegates presence at the meeting to "E".

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;PARTSTAT=DELEGATED;DELEGATED-
    TO="Mailto:E@example.com":Mailto:C@example.com
   ATTENDEE;RSVP=TRUE;
    DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
   DTSTART:19970701T180000Z
   DTEND:19970701T200000Z
   SUMMARY:Phone Conference
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   STATUS:CONFIRMED
   DTSTAMP:19970611T190000Z
   END:VEVENT
   END:VCALENDAR

4.2.6 Delegate Accepts the Meeting

   To accept a delegated meeting, the delegate, "E", sends the following
   message to "A" and "C":

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0

Silverberg, et. al.         Standards Track                    [Page 70]

RFC 2446                          iTIP                     November 1998

   BEGIN:VEVENT
   ORGANIZER:MAILTO:A@Example.com
   ATTENDEE;PARTSTAT=ACCEPTED;DELEGATED-
    FROM="Mailto:C@example.com":Mailto:E@example.com
   ATTENDEE;PARTSTAT=DELEGATED;
    DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   REQUEST-STATUS:2.0;Success
   DTSTAMP:19970614T190000Z
   END:VEVENT
   END:VCALENDAR

4.2.7 Delegate Declines the Meeting

   In this example the "Delegate" declines the meeting request and sets
   the "ATTENDEE" property "partstat" parameter to "DECLINED". The
   "Organizer" SHOULD resend the "REQUEST" to "C" with the "partstat"
   parameter of the "Delegate" set to "declined". This lets the
   "Delegator" know that the "Delegate" has declined and provides an
   opportunity to the "Delegator" to either accept the request or
   delegate it to another CU.

   Response from "E" to "A" and "C". Note the use of the "COMMENT"
   property "E" uses to indicate why the delegation was declined.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:MAILTO:A@Example.com
   ATTENDEE;PARTSTAT=DELEGATED;
    DELEGATED-TO="Mailto:E@example.com":Mailto:C@example.com
   ATTENDEE;PARTSTAT=DECLINED;
    DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
   COMMENT:Sorry, I will be out of town at that time.
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   REQUEST-STATUS:2.0;Success
   DTSTAMP:19970614T190000Z
   END:VEVENT
   END:VCALENDAR

   "A" resends the "REQUEST" method to "C". "A" may also wish to express
   the fact that the item was delegated in the "COMMENT" property.

Silverberg, et. al.         Standards Track                    [Page 71]

RFC 2446                          iTIP                     November 1998

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:MAILTO:A@Example.com
   ATTENDEE;PARTSTAT=DECLINED;
    DELEGATED-FROM="Mailto:C@example.com":Mailto:E@example.com
   ATTENDEE;RSVP=TRUE:Mailto:C@example.com
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   SUMMARY:Phone Conference
   DTSTART:19970701T180000Z
   DTEND:19970701T200000Z
   DTSTAMP:19970614T200000Z
   COMMENT:DELEGATE (ATTENDEE Mailto:E@example.com) DECLINED YOUR
    INVITATION
   END:VEVENT
   END:VCALENDAR

4.2.8 Forwarding an Event Request

   The protocol does not prevent an "Attendee" from "forwarding" an
   "VEVENT" calendar component to other "Calendar Users". Forwarding
   differs from delegation in that the forwarded "Calendar User" (often
   referred to as a "Party Crasher") does not replace the forwarding
   "Calendar User". Implementations are not required to add the "Party
   Crasher" to the "Attendee" list and hence there is no guarantee that
   a "Party Crasher" will receive additional updates to the Event. The
   forwarding "Calendar User" SHOULD NOT add the "Party Crasher" to the
   attendee list. The "Organizer" MAY add the forwarded "Calendar User"
   to the attendee list.

4.2.9 Cancel A Group Event

   Individual "A" requests a meeting between individuals "A", "B", "C",
   and "D". Individual "B" declines attendance to the meeting.
   Individual "A" decides to cancel the meeting. The following table
   illustrates the sequence of messages that would be exchanged between
   these individuals.

   Messages related to a previously canceled event ("SEQUENCE" property
   value is less than the "SEQUENCE" property value of the "CANCEL"
   message) MUST be ignored.

Silverberg, et. al.         Standards Track                    [Page 72]

RFC 2446                          iTIP                     November 1998

   +--------------------------------------------------------------------+
   | Action             |  "Organizer"        | "Attendee"              |
   +--------------------------------------------------------------------+
   | Initiate a meeting | "A" sends a REQUEST |                         |
   | request            | message to "B", "C",|                         |
   |                    | and "D"             |                         |
   +--------------------------------------------------------------------+
   | Decline the meeting|                     | "B" sends a "REPLY"     |
   | request            |                     | message to "A" with its |
   |                    |                     | "partstat" para-         |
   |                    |                     | set to "declined".      |
   +--------------------------------------------------------------------+
   | Cancel the meeting | "A" sends a CANCEL  |                         |
   |                    | message to "B", "C" |                         |
   |                    | and "D"             |                         |
   +--------------------------------------------------------------------+

   The example shows how "A" cancels the event.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:CANCEL
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;TYPE=INDIVIDUAL;Mailto:A@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
   COMMENT:Mr. B cannot attend. It's raining. Lets cancel.
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:1
   STATUS:CANCELLED
   DTSTAMP:19970613T190000Z
   END:VEVENT
   END:VCALENDAR

Silverberg, et. al.         Standards Track                    [Page 73]

RFC 2446                          iTIP                     November 1998

4.2.10 Removing Attendees

   "A" wants to remove "B" from a meeting. This is done by sending a
   "CANCEL" to "B" and removing "B" from the attendee list in the master
   copy of the event.

   +--------------------------------------------------------------------+
   | Action             |  "Organizer"        | "Attendee"              |
   +--------------------------------------------------------------------+
   | Remove an "B"      | "A" sends a CANCEL  |                         |
   | as an "Attendee"   | message to "B"      |                         |
   +--------------------------------------------------------------------+
   | Update the master  | "A" sends the       |                         |
   | copy of the event  | updated event to    |                         |
   |                    | the remaining       |                         |
   |                    | "Attendees"         |                         |
   +--------------------------------------------------------------------+

   The original meeting includes "A", "B", "C", and "D". The example
   below shows the "CANCEL" that "A" sends to "B". Note that in the
   example below the "STATUS" property is omitted. This is used when the
   meeting itself is cancelled and not when the intent is to remove an
   "Attendee" from the Event.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:CANCEL
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE:mailto:B@example.com
   COMMENT:You're off the hook for this meeting
   UID:calsrv.example.com-873970198738777@example.com
   DTSTAMP:19970613T193000Z
   SEQUENCE:1
   END:VEVENT
   END:VCALENDAR

   The updated master copy of the event is shown below. The "Organizer"
   MAY resend the updated event to the remaining "Attendees". Note that
   "B" has been removed.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com

Silverberg, et. al.         Standards Track                    [Page 74]

RFC 2446                          iTIP                     November 1998

   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
   ATTENDEE;TYPE=ROOM:CR_Big@example.com
   ATTENDEE;ROLE=NON-PARTICIPANT;
    RSVP=FALSE:Mailto:E@example.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T200000Z
   DTEND:19970701T203000Z
   SUMMARY:Phone Conference
   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:2
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.2.11 Replacing the Organizer

   The scenario for this example begins with "A" as the "Organizer" for
   a recurring meeting with "B", "C", and "D". "A" receives a new job
   offer in another country and drops out of touch.  "A" left no
   forwarding address or way to be reached.  Using out-of-band
   communication, the other "Attendees" eventually learn what has
   happened and reach an agreement that "B" should become the new
   "Organizer" for the meeting. To do this, "B" sends out a new version
   of the event and the other "Attendees" agree to accept "B" as the new
   "Organizer". "B" also removes "A" from the event.

   When the "Organizer" is replaced, the "SEQUENCE" property value MUST
   be incremented.

   This is the message "B" sends to "C" and "D"

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:B@example.com
   ATTENDEE;ROLE=CHAIR;STATUS=ACCEPTED:Mailto:B@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:C@example.com
   ATTENDEE;TYPE=INDIVIDUAL:Mailto:D@example.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T200000Z
   DTEND:19970701T203000Z
   RRULE:FREQ=WEEKLY
   SUMMARY:Phone Conference
   UID:123456@example.com

Silverberg, et. al.         Standards Track                    [Page 75]

RFC 2446                          iTIP                     November 1998

   SEQUENCE:1
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.3 Busy Time Examples

   Busy time objects can be used in several ways. First, a CU may
   request busy time from another CU for a specific range of time. That
   request can be answered with a busy time Reply. Additionally, a CU
   may simply publish their busy time for a given interval and point
   other CUs to the published location. The following examples outline
   both scenarios.

   Individual "A" publishes busy time for one week.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   VERSION:2.0
   METHOD:PUBLISH
   BEGIN:VFREEBUSY
   DTSTAMP:19980101T124100Z
   ORGANIZER:MAILTO:A@Example.com
   DTSTART:19980101T124200Z
   DTEND:19980107T124200Z
   FREEBUSY:19980101T180000Z/19980101T190000Z
   FREEBUSY:19980103T020000Z/19980103T050000Z
   FREEBUSY:19980107T020000Z/19980107T050000Z
   FREEBUSY:19980113T000000Z/19980113T010000Z
   FREEBUSY:19980115T190000Z/19980115T200000Z
   FREEBUSY:19980115T220000Z/19980115T230000Z
   FREEBUSY:19980116T013000Z/19980116T043000Z
   END:VFREEBUSY
   END:VCALENDAR

   Individual "A" requests busy time from individuals "B", "C".
   Individual "B" and "C" replies with busy time data to individual "A".
   The following table illustrates the sequence of messages that would
   be exchanged between these individuals.

Silverberg, et. al.         Standards Track                    [Page 76]

RFC 2446                          iTIP                     November 1998

+--------------------------------------------------------------------+
| Action             |  "Organizer"        | Attendee                |
+--------------------------------------------------------------------+
| Initiate a busy    | "A" sends "REQUEST" |                         |
| time request       | message to "B" and  |                         |
|                    | and "C"             |                         |
+--------------------------------------------------------------------+
| Reply to the "BUSY"|                     | "B" sends a "REPLY"     |
| request with "BUSY"|                     | message to "A" with     |
| time data          |                     | busy time data          |
+--------------------------------------------------------------------+

4.3.1 Request Busy Time

   "A" sends a "BUSY-REQUEST" to "B" and "C" for busy time

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VFREEBUSY
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
   ATTENDEE:Mailto:B@example.com
   ATTENDEE:Mailto:C@example.com
   DTSTAMP:19970613T190000Z
   DTSTART:19970701T080000Z
   DTEND:19970701T200000
   UID:calsrv.example.com-873970198738777@example.com
   END:VFREEBUSY
   END:VCALENDAR

4.3.2 Reply To A Busy Time Request

   "B" sends a "REPLY" method type of a "VFREEBUSY" calendar component
   to "A"

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VFREEBUSY
   ORGANIZER:MAILTO:A@example.com
   ATTENDEE:Mailto:B@example.com
   DTSTART:19970701T080000Z
   DTEND:19970701T200000Z
   UID:calsrv.example.com-873970198738777@example.com
   FREEBUSY:19970701T090000Z/PT1H,19970701T140000Z/PT30M

Silverberg, et. al.         Standards Track                    [Page 77]

RFC 2446                          iTIP                     November 1998

   DTSTAMP:19970613T190030Z
   END:VFREEBUSY
   END:VCALENDAR

   "B" is busy from 09:00 to 10:00 and from 14:00 to 14:30.

4.4 Recurring Event and Time Zone Examples

4.4.1 A Recurring Event Spanning Time Zones

   This event describes a weekly phone conference. The "Attendees" are
   each in a different time zone.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VTIMEZONE
   TZID:America-SanJose
   TZURL:http://zones.stds_r_us.net/tz/America-SanJose
   BEGIN:STANDARD
   DTSTART:19671029T020000
   RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10
   TZOFFSETFROM:-0700
   TZOFFSETTO:-0800
   TZNAME:PST
   END:STANDARD
   BEGIN:DAYLIGHT
   DTSTART:19870405T020000
   RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4
   TZOFFSETFROM:-0800
   TZOFFSETTO:-0700
   TZNAME:PDT
   END:DAYLIGHT
   END:VTIMEZONE
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:A@example.COM
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:B@example.fr
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:c@example.jp
   DTSTAMP:19970613T190030Z
   DTSTART;TZID=America-SanJose:19970701T140000
   DTEND;TZID=America-SanJose:19970701T150000
   RRULE:FREQ=WEEKLY;INTERVAL=20;WKST=SU;BYDAY=TU
   RDATE;TZID=America-SanJose:19970910T140000
   EXDATE;TZID=America-SanJose:19970909T140000
   EXDATE;TZID=America-SanJose:19971028T140000
   SUMMARY:Weekly Phone Conference

Silverberg, et. al.         Standards Track                    [Page 78]

RFC 2446                          iTIP                     November 1998

   UID:calsrv.example.com-873970198738777@example.com
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   The first two components of this iCalendar object are the time zone
   components. The "DTSTART" date coincides with the first instance of
   the RRULE property.

   The recurring meeting is defined in a particular time zone,
   presumably that of the originator. The client for each "Attendee" has
   the responsibility of determining the recurrence time in the
   "Attendee's" time zone.

   The repeating event starts on Tuesday, July 1, 1997 at 2:00pm PDT.
   "Attendee" B@example.fr is in France where the local time on this
   date is 9 hours ahead of PDT or 23:00. "Attendee" C@example.jp is in
   Japan where local time is 8 hours ahead of UTC or Wednesday, July 2
   at 06:00.  The event repeats weekly on Tuesdays (in PST/PDT). The
   "RRULE" property results in 20 instances. The last instance falls on
   Tuesday, November 11, 1997 2:00pm PDT. The "RDATE" property adds
   another instance: WED, 10-SEP-1997 2:00 PM PST.

   There are two exceptions to this recurring appointment. The first one
   is:

   TUE, 09-SEP-1997 23:00 GMT
   TUE, 09-SEP-1997 14:00 PDT
   WED, 10-SEP-1997 06:00 JST

   and the second is:

   TUE, 28-OCT-1997 23:00 GMT
   TUE, 28-OCT-1997 14:00 PST
   WED, 29-OCT-1997 06:00 JST

4.4.2 Modify A Recurring Instance

   In this example the "Organizer" issues a recurring meeting. Later the
   "Organizer" changes an instance of the event by changing the
   "DTSTART" property. Note the use of "RECURRENCE-ID" property and
   "SEQUENCE" property in the second request.

   Original Request:

   BEGIN:VCALENDAR
   METHOD:REQUEST

Silverberg, et. al.         Standards Track                    [Page 79]

RFC 2446                          iTIP                     November 1998

   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:guid-1@host1.com
   SEQUENCE:0
   RRULE:FREQ=MONTHLY;BYMONTHDAY=1;UNTIL=19980901T210000Z
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE:Mailto:B@example.com
   ATTENDEE:Mailto:C@example.com
   ATTENDEE:Mailto:D@example.com
   DESCRIPTION:IETF-C&S Conference Call
   CLASS:PUBLIC
   SUMMARY:IETF Calendaring Working Group Meeting
   DTSTART:19970601T210000Z
   DTEND:19970601T220000Z
   LOCATION:Conference Call
   DTSTAMP:19970526T083000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   The event request below is to change the time of a specific instance.
   This changes the July 1st instance to July 3rd.

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:guid-1@host1com
   RECURRENCE-ID:19970701T210000Z
   SEQUENCE:1
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE:Mailto:B@example.com
   ATTENDEE:Mailto:C@example.com
   ATTENDEE:Mailto:D@example.com
   DESCRIPTION:IETF-C&S Conference Call
   CLASS:PUBLIC
   SUMMARY:IETF Calendaring Working Group Meeting
   DTSTART:19970703T210000Z
   DTEND:19970703T220000Z
   LOCATION:Conference Call
   DTSTAMP:19970626T093000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

Silverberg, et. al.         Standards Track                    [Page 80]

RFC 2446                          iTIP                     November 1998

4.4.3 Cancel an Instance

   In this example the "Organizer" of a recurring event deletes the
   August 1st instance.

   BEGIN:VCALENDAR
   METHOD:CANCEL
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:guid-1@host1.com
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE:Mailto:B@example.com
   ATTENDEE:Mailto:C@example.com
   ATTENDEE:Mailto:D@example.com
   RECURRENCE-ID:19970801T210000Z
   SEQUENCE:2
   STATUS:CANCELLED
   DTSTAMP:19970721T093000Z
   END:VEVENT
   END:VCALENDAR

4.4.4 Cancel Recurring Event

   In this example the "Organizer" wishes to cancel the entire recurring
   event and any exceptions.

   BEGIN:VCALENDAR
   METHOD:CANCEL
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:guid-1@host1.com
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE:Mailto:B@example.com
   ATTENDEE:Mailto:C@example.com
   ATTENDEE:Mailto:D@example.com
   DTSTAMP:19970721T103000Z
   STATUS:CANCELLED
   SEQUENCE:3
   END:VEVENT
   END:VCALENDAR

Silverberg, et. al.         Standards Track                    [Page 81]

RFC 2446                          iTIP                     November 1998

4.4.5 Change All Future Instances

   This example changes the meeting location from a conference call to
   Seattle starting September 1 and extends to all future instances.

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:guid-1@host1.com
   RECURRENCE-ID;THISANDFUTURE:19970901T210000Z
   SEQUENCE:3
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE:Mailto:C@example.com
   ATTENDEE;RSVP=TRUE:Mailto:D@example.com
   DESCRIPTION:IETF-C&S Discussion
   CLASS:PUBLIC
   SUMMARY:IETF Calendaring Working Group Meeting
   DTSTART:19970901T210000Z
   DTEND:19970901T220000Z
   LOCATION:Building 32, Microsoft, Seattle, WA
   DTSTAMP:19970526T083000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.4.6 Add A New Instance To A Recurring Event

   This example adds a one-time additional instance to the recurring
   event.  "Organizer" adds a second July meeting on the 15th.

   BEGIN:VCALENDAR
   METHOD:ADD
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:123456789@host1.com
   SEQUENCE:4
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE:Mailto:C@example.com
   ATTENDEE;RSVP=TRUE:Mailto:D@example.com
   DESCRIPTION:IETF-C&S Conference Call
   CLASS:PUBLIC

Silverberg, et. al.         Standards Track                    [Page 82]

RFC 2446                          iTIP                     November 1998

   SUMMARY:IETF Calendaring Working Group Meeting
   DTSTART:19970715T210000Z
   DTEND:19970715T220000Z
   LOCATION:Conference Call
   DTSTAMP:19970629T093000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.4.7 Add A New Series of Instances To A Recurring Event

   The scenario for this example involves an ongoing meeting, originally
   set up to occur every Tuesday.  The "Organizer" later decides that
   the meetings need to be on Tuesdays and Thursdays, but does not want
   to reschedule the entire meeting or lose any of the per-instance
   information already collected.

   The original event:

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:123456789@host1.com
   SEQUENCE:0
   RRULE:WKST=SU;BYDAY=TU;FREQ=WEEKLY
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   SUMMARY:Review Accounts
   DTSTART:19980303T210000Z
   DTEND:19980303T220000Z
   LOCATION:The White Room
   DTSTAMP:19980301T093000Z
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   Assume that many other updates happen to this event and that a lot of
   instance-specific information exists in the recurring series. The
   "SEQUENCE" property value is 7 for the next update. Now the
   "Organizer" wants to add Thursdays to the event:

   BEGIN:VCALENDAR
   METHOD:ADD
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0

Silverberg, et. al.         Standards Track                    [Page 83]

RFC 2446                          iTIP                     November 1998

   BEGIN:VEVENT
   UID:123456789@host1.com
   SEQUENCE:7
   RRULE:WKST=SU;BYDAY=TH;FREQ=WEEKLY
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   SUMMARY:Review Accounts
   DTSTART:19980303T210000Z
   DTEND:19980303T220000Z
   DTSTAMP:19980303T193000Z
   LOCATION:The Usual conference room
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   Alternatively, if the "Organizer" is not concerned with per-instance
   updates, the entire event can be rescheduled using a "REQUEST". This
   is done by using the "UID" of the event to reschedule and including
   the modified "RRULE". Note, that since this is an entire rescheduling
   of the event, any instance-specific information will be lost.

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:123456789@host1.com
   SEQUENCE:7
   RRULE:WKST=SU;BYDAY=TU,TH;FREQ=WEEKLY
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   SUMMARY:Review Accounts
   DTSTART:19980303T210000Z
   DTEND:19980303T220000Z
   DTSTAMP:19980303T193000Z
   LOCATION:The White Room
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   The next series of examples illustrate how an "Organizer" would
   respond to a "REFRESH" submitted by an "Attendee" after a series of
   instance-specific modifications. To convey all instance-specific
   changes, the "Organizer" must provide the latest event description
   and the relevant instances. The first three examples show the history
   including the initial "VEVENT" request and subsequent instance

Silverberg, et. al.         Standards Track                    [Page 84]

RFC 2446                          iTIP                     November 1998

   changes and finally the "REFRESH".

   Original Request:

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:123456789@host1.com
   SEQUENCE:0
   RDATE:19980304T180000Z
   RDATE:19980311T180000Z
   RDATE:19980318T180000Z
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   SUMMARY:Review Accounts
   DTSTART:19980304T180000Z
   DTEND:19980304T200000Z
   DTSTAMP:19980303T193000Z
   LOCATION:Conference Room A
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   Organizer changes 2nd instance Location and Time:

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:123456789@host1.com
   SEQUENCE:1
   RECURRENCE-ID:19980311T180000Z
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   SUMMARY:Review Accounts
   DTSTART:19980311T160000Z
   DTEND:19980311T180000Z
   DTSTAMP:19980306T193000Z
   LOCATION:The Small conference room
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

Silverberg, et. al.         Standards Track                    [Page 85]

RFC 2446                          iTIP                     November 1998

   Organizer adds a 4th instance of the meeting using the "ADD" method

   BEGIN:VCALENDAR
   METHOD:ADD
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:123456789@host1.com
   SEQUENCE:2
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   SUMMARY:Review Accounts
   DTSTART:19980315T180000Z
   DTEND:19980315T200000Z
   DTSTAMP:19980307T193000Z
   LOCATION:Conference Room A
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   If "B" requests a "REFRESH", "A" responds with the following to
   capture all instance-specific data. In this case both the initial
   request and an additional "VEVENT" that specifies the instance-
   specific data are included. Because these are both of the same type
   (they are both "VEVENTS"), they can be conveyed in the same iCalendar
   object.

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:123456789@host1.com
   SEQUENCE:2
   RDATE:19980304T180000Z
   RDATE:19980311T160000Z
   RDATE:19980315T180000Z
   Error! Bookmark not defined.
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   SUMMARY:Review Accounts
   DTSTART:19980304T180000Z
   DTEND:19980304T200000Z
   DTSTAMP:19980303T193000Z
   LOCATION:Conference Room A
   STATUS:CONFIRMED

Silverberg, et. al.         Standards Track                    [Page 86]

RFC 2446                          iTIP                     November 1998

   END:VEVENT

   BEGIN:VEVENT
   Error! Bookmark not defined.
   SEQUENCE:2
   RECURRENCE-ID:19980311T160000Z
   Error! Bookmark not defined.
   ATTENDEE;ROLE=CHAIR;Error! Bookmark not defined.
   ATTENDEE;Error! Bookmark not defined.
   SUMMARY:Review Accounts
   DTSTART:19980311T160000Z
   DTEND:19980304T180000Z
   DTSTAMP:19980306T193000Z
   LOCATION:The Small conference room
   STATUS:CONFIRMED
   END:VEVENT

   END:VCALENDAR

4.4.8 Counter An Instance Of A Recurring Event

   In this example one of the "Attendees" counters the "DTSTART"
   property of the proposed second July meeting.

   BEGIN:VCALENDAR
   METHOD:COUNTER
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:guid-1@host1.com
   RECURRENCE-ID:19970715T210000Z
   SEQUENCE:4
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;RSVP=TRUE:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE:Mailto:C@example.com
   ATTENDEE;RSVP=TRUE:Mailto:D@example.com
   DESCRIPTION:IETF-C&S Conference Call
   CLASS:PUBLIC
   SUMMARY:IETF Calendaring Working Group Meeting
   DTSTART:19970715T220000Z
   DTEND:19970715T230000Z
   LOCATION:Conference Call
   COMMENT:May we bump this by an hour? I have a conflict
   DTSTAMP:19970629T094000Z
   END:VEVENT
   END:VCALENDAR

Silverberg, et. al.         Standards Track                    [Page 87]

RFC 2446                          iTIP                     November 1998

4.4.9 Error Reply To A Request

   The following example illustrates a scenario where a meeting is
   proposed containing an unsupported property and a bad property.

   Original Request

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:guid-1@host1.com
   SEQUENCE:0
   RRULE:FREQ=MONTHLY;BYMONTHDAY=1
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE:Mailto:C@example.com
   ATTENDEE;RSVP=TRUE:Mailto:D@example.com
   DESCRIPTION:IETF-C&S Conference Call
   CLASS:PUBLIC
   SUMMARY:IETF Calendaring Working Group Meeting
   DTSTART:19970601T210000Z
   DTEND:19970601T220000Z
   DTSTAMP:19970602T094000Z
   LOCATION:Conference Call
   STATUS:CONFIRMED
   FOO:BAR
   END:VEVENT
   END:VCALENDAR

   Response from "B" to indicate that RRULE is not supported and an
   unrecognized property was encountered

   BEGIN:VCALENDAR
   PRODID:-//RDU Software//NONSGML HandCal//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE:Mailto:B@example.com
   REQUEST-STATUS:2.8;Repeating event ignored. Scheduled as a single
     event;RRULE
   REQUEST-STATUS:3.0;Invalid Property Name;FOO
   UID:guid-1@host1.com
   SEQUENCE:0
   DTSTAMP:19970603T094000Z

Silverberg, et. al.         Standards Track                    [Page 88]

RFC 2446                          iTIP                     November 1998

   END:VEVENT
   END:VCALENDAR

4.5 Group To-do Examples

   Individual "A" creates a group task in which individuals "A", "B",
   "C" and "D" will participate. Individual "B" confirms acceptance of
   the task. Individual "C" declines the task. Individual "D"
   tentatively accepts the task. The following table illustrates the
   sequence of messages that would be exchanged between these
   individuals. Individual "A" then issues a "REQUEST" method to obtain
   the status of the to-do from each participant. The response indicates
   the individual "Attendee's" completion status. The table below
   illustrates the message flow.

+--------------------------------------------------------------------+
| Action             |  "Organizer"        | Attendee                |
+--------------------------------------------------------------------+
| Initiate a to-do   | "A" sends a REQUEST |                         |
| request            | message to "B", "C",|                         |
|                    | and "D"             |                         |
+--------------------------------------------------------------------+
| Accept the to-do   |                     | "B" sends a "REPLY"     |
| request            |                     | message to "A" with its |
|                    |                     | "partstat" paramater    |
|                    |                     | set to "accepted".      |
+--------------------------------------------------------------------+
| Decline the to-do  |                     | "C" sends a REPLY       |
| request            |                     | message to "A" with its |
|                    |                     | "partstat" parameter    |
|                    |                     | set to "declined".      |
+--------------------------------------------------------------------+
| Tentatively accept |                     | "D" sends a REPLY       |
| the to-do request  |                     | message to "A" with its |
|                    |                     | "partstat" parameter    |
|                    |                     | set to "tentative".     |
+--------------------------------------------------------------------+
| Check attendee     | "A" sends a REQUEST |                         |
| completion status  | message to "B" and  |                         |
|                    | "D" with current    |                         |
|                    | information.        |                         |
+--------------------------------------------------------------------+
| Attendee indicates |                     | "B" sends a "REPLY"     |
| percent complete   |                     | message indicating      |
|                    |                     | percent complete        |

Silverberg, et. al.         Standards Track                    [Page 89]

RFC 2446                          iTIP                     November 1998

+--------------------------------------------------------------------+
| Attendee indicates |                     | "D" sends a "REPLY"     |
| completion         |                     | message indicating      |
|                    |                     | completion              |
+--------------------------------------------------------------------+

4.5.1 A VTODO Request

   A sample "REQUEST" for a "VTODO" calendar component that "A" sends to
   "B", "C", and "D".

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VTODO
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE:Mailto:C@example.com
   ATTENDEE;RSVP=TRUE:Mailto:D@example.com
   DTSTART:19970701T170000Z
   DUE:19970722T170000Z
   PRIORITY:1
   SUMMARY:Create the requirements document
   UID:calsrv.example.com-873970198738777-00@example.com
   SEQUENCE:0
   DTSTAMP:19970717T200000Z
   STATUS:Needs Action
   END:VTODO
   END:VCALENDAR

4.5.2 A VTODO Reply

   "B" accepts the to-do.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VTODO
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;PARTSTAT=ACCEPTED:Mailto:B@example.com
   UID:calsrv.example.com-873970198738777-00@example.com
   COMMENT:I'll send you my input by e-mail
   SEQUENCE:0
   DTSTAMP:19970717T203000Z
   REQUEST-STATUS:2.0;Success

Silverberg, et. al.         Standards Track                    [Page 90]

RFC 2446                          iTIP                     November 1998

   END:VTODO
   END:VCALENDAR

   "B" could have declined the TODO or indicated tentative acceptance by
   setting the "partstat" property parameter sequence to "declined" or
   "tentative", respectively.

4.5.3 A VTODO Request for Updated Status

   "A" requests status from all "Attendees".

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VTODO
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com
   UID:calsrv.example.com-873970198738777-00@example.com
   SUMMARY:Create the requirements document
   PRIORITY:1
   SEQUENCE:0
   STATUS:IN-PROCESS
   DTSTART:19970701T170000Z
   DTSTAMP:19970717T230000Z
   END:VTODO
   END:VCALENDAR

4.5.4 A Reply: Percent-Complete

   A reply indicating the task being worked on and that "B" is 75%
   complete with "B's" part of the assignment.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VTODO
   ORGANIZER:MAILTO:A@example.com
   ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com
   PERCENT-COMPLETE:75
   UID:calsrv.example.com-873970198738777-00@example.com
   DTSTAMP:19970717T233000Z
   SEQUENCE:0
   END:VTODO
   END:VCALENDAR

Silverberg, et. al.         Standards Track                    [Page 91]

RFC 2446                          iTIP                     November 1998

4.5.5 A Reply: Completed

   A reply indicating that "D" completed "D's" part of the assignment.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0
   BEGIN:VTODO
   ORGANIZER:MAILTO:A@example.com
   ATTENDEE;PARTSTAT=COMPLETED:Mailto:D@example.com
   UID:calsrv.example.com-873970198738777-00@example.com
   DTSTAMP:19970717T233000Z
   SEQUENCE:0
   END:VTODO
   END:VCALENDAR

4.5.6 An Updated VTODO Request

   Organizer "A" resends the "VTODO" calendar component. "A" sets the
   overall completion for the to-do at 40%.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VTODO
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE;PARTSTAT=ACCEPTED;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;PARTSTAT=IN-PROCESS;TYPE=INDIVIDUAL:Mailto:D@example.com
   DTSTART:19970701T170000Z
   DUE:19970722T170000Z
   PRIORITY:1
   SUMMARY:Create the requirements document
   UID:calsrv.example.com-873970198738777-00@example.com
   SEQUENCE:1
   DTSTAMP:19970718T100000Z
   STATUS:IN-PROGRESS
   PERCENT-COMPLETE:40
   END:VTODO
   END:VCALENDAR

4.5.7 Recurring VTODOs

   The following examples relate to recurring "VTODO" calendar
   components.

Silverberg, et. al.         Standards Track                    [Page 92]

RFC 2446                          iTIP                     November 1998

4.5.7.1 Request for a Recurring VTODO

   In this example "A" sends a recurring "VTODO" calendar component to
   "B" and "D".

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VTODO
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR:Mailto:A@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:B@example.com
   ATTENDEE;RSVP=TRUE;TYPE=INDIVIDUAL:Mailto:D@example.com
   RRULE:FREQ=MONTHLY;COUNT=10;BYDAY=1FR
   DTSTART:19980101T100000-0700
   DUE:19980103T100000-0700
   SUMMARY:Send Status Reports to Area Managers
   UID:calsrv.example.com-873970198738777-00@example.com
   SEQUENCE:0
   DTSTAMP:19970717T200000Z
   STATUS:NEEDS ACTION
   PRIORITY:1
   END:VTODO
   END:VCALENDAR

4.5.7.2 Calculating due dates in recurring VTODOs

   The due date in a recurring "VTODO" calendar component is either a
   fixed interval specified in the "REQUEST" method or specified using
   the "RECURRENCE-ID" property. The former is calculated by applying
   the difference between "DTSTART" and "DUE" properties and applying it
   to each of the start of each recurring instance. Hence, if the
   initial "VTODO" calendar component specifies a "DTSTART" property
   value of "19970701T190000Z" and a "DUE" property value of
   "19970801T190000Z" the interval of one day which is applied to each
   recurring instance of the "VTODO" calendar component to determine the
   "DUE" date of the instance.

4.5.7.3 Replying to an instance of a recurring VTODO

   In this example "B" updates "A" on a single instance of the "VTODO"
   calendar component.

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REPLY
   VERSION:2.0

Silverberg, et. al.         Standards Track                    [Page 93]

RFC 2446                          iTIP                     November 1998

   BEGIN:VTODO
   ATTENDEE;PARTSTAT=IN-PROCESS:Mailto:B@example.com
   PERCENT-COMPLETE:75
   UID:calsrv.example.com-873970198738777-00@example.com
   DTSTAMP:19970717T233000Z
   RECURRENCE-ID:19980101T170000Z
   SEQUENCE:1
   END:VTODO
   END:VCALENDAR

4.6 Journal Examples

   The iCalendar object below describes a single journal entry for
   October 2, 1997. The "RELATED-TO" property references the phone
   conference event for which minutes were taken.

   BEGIN:VCALENDAR
   METHOD:PUBLISH
   PRODID:-//ACME/DesktopCalendar//EN
   VERSION:2.0
   BEGIN:VJOURNAL
   DTSTART:19971002T200000Z
   ORGANIZER:MAILTO:A@Example.com
   SUMMARY:Phone conference minutes
   DESCRIPTION:The editors meeting was held on October 1, 1997.
     Details are in the attached document.
   UID:0981234-1234234-2410@example.com
   RELATED-TO:0981234-1234234-2402-35@example.com
   ATTACH:ftp://ftp.example.com/pub/ed/minutes100197.txt
   END:VJOURNAL
   END:VCALENDAR

4.7 Other Examples

4.7.1 Event Refresh

   Refresh the event with "UID" property value of "guid-1-
   12345@host1.com":

   BEGIN:VCALENDAR
   PRODID:-//RDU Software//NONSGML HandCal//EN
   METHOD:REFRESH
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE:Mailto:B@example.com
   ATTENDEE:Mailto:C@example.com

Silverberg, et. al.         Standards Track                    [Page 94]

RFC 2446                          iTIP                     November 1998

   ATTENDEE:Mailto:D@example.com
   UID: guid-1-12345@host1.com
   DTSTAMP:19970603T094000
   END:VEVENT
   END:VCALENDAR

4.7.2 Bad RECURRENCE-ID

   Component instances are identified by the combination of "UID",
   "RECURRENCE-ID", and "SEQUENCE". When an "Organizer" sends a request
   to an "Attendee", there are three cases in which an instance cannot
   be found.  They are:

   1.  The component with the referenced "UID" and "RECURRENCE-ID" has
       been found but the "SEQUENCE" number in the calendar store does
       not match that of the ITIP message.

   2.  The component with the referenced "UID" has been found, the
       "SEQUENCE" numbers match, but the "RECURRENCE-ID" cannot be
       found.

   3.  The "UID" and "SEQUENCE" numbers are found but the CUA does not
       support recurrences.

   In case (1), two things can happen. If the "SEQUENCE" number of the
   "Attendee's" instance is larger than that in the "Organizer's"
   message then the "Attendee" is receiving an out-of-sequence message
   and MUST ignore it.  If the "SEQUENCE" number of the "Attendee's"
   instance is smaller, then the "Organizer" is sending out a newer
   version of the component and the "Attendee's" version needs to be
   updated. Since one or more updates have been missed, the "Attendee"
   SHOULD send a "REFRESH" message to the "Organizer" to get an updated
   version of the event.

   In case (2), something has gone wrong.  Both the "Organizer" and the
   "Attendee" should have the same instances, but the "Attendee" does
   not have the referenced instance.  In this case the "Attendee" SHOULD
   send a "REFRESH" to the "Organizer" to get an updated version of the
   event.

   In case (3), the limitations of the "Attendee's" CUA makes it
   impossible to match an instance other than the single instance
   scheduled. In this case, the "Attendee" need not send a "REFRESH" to
   the "Organizer".

   The example below shows a sequence in which an "Attendee" sends a
   "REFRESH" to the "Organizer".

Silverberg, et. al.         Standards Track                    [Page 95]

RFC 2446                          iTIP                     November 1998

+--------------------------------------------------------------------+
| Action             |  "Organizer"        | Attendee                |
+--------------------------------------------------------------------+
| Update an instance | "A" sends  "REQUEST"|                         |
| request            | message to "B"      |                         |
+--------------------------------------------------------------------+
| Attendee requests  |                     | "B" sends a "REFRESH"   |
| refresh because    |                     | message to "A"          |
| "RECURRENCE-ID" was|                     |                         |
| not found          |                     |                         |
+--------------------------------------------------------------------+
| Refresh the entire | "A" sends the       |                         |
| Event              | latest copy of the  |                         |
|                    | Event to "B"        |                         |
+--------------------------------------------------------------------+
| Attendee handles   |                     | "B" updates to the      |
| the request and    |                     | latest copy of the      |
| updates the        |                     | meeting.                |
| instance           |                     |                         |
+--------------------------------------------------------------------+

   Request from "A":

   BEGIN:VCALENDAR
   METHOD:REQUEST
   PRODID:-//RDU Software//NONSGML HandCal//EN
   VERSION:2.0
   BEGIN:VEVENT
   UID:acme-12345@host1.com
   SEQUENCE:3
   RRULE:FREQ=WEEKLY
   RDATE;VALUE=PERIOD:19970819T210000Z/199700819T220000Z
   ORGANIZER:Mailto:A@example.com
   ATTENDEE;ROLE=CHAIR;PARTSTAT=ACCEPTED:Mailto:A@example.com
   ATTENDEE:Mailto:B@example.com
   DESCRIPTION:IETF-C&S Conference Call
   SUMMARY:IETF Calendaring Working Group Meeting
   DTSTART:19970801T210000Z
   DTEND:19970801T220000Z
   RECURRENCE-ID:19970809T210000Z
   DTSTAMP:19970726T083000
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   "B" has the event with "UID" property "acme-12345@host1.com" but
   "B's" "SEQUENCE" property value is "1" and the event does not have an
   instance at the specified recurrence time. This means that "B" has

Silverberg, et. al.         Standards Track                    [Page 96]

RFC 2446                          iTIP                     November 1998

   missed at least one update and needs a new copy of the event.  "B"
   requests the latest copy of the event with the following refresh
   message:

   BEGIN:VCALENDAR
   PRODID:-//RDU Software//NONSGML HandCal//EN
   METHOD:REFRESH
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:Mailto:A@example.com
   ATTENDEE:Mailto:B@example.com
   UID:acme-12345@host1.com
   DTSTAMP:19970603T094000
   END:VEVENT
   END:VCALENDAR

5 Application Protocol Fallbacks

5.1 Partial Implementation

   Applications that support this memo are not required to support the
   entire protocol. The following describes how methods and properties
   SHOULD "fallback" in applications that do not support the complete
   protocol. If a method or property is not addressed in this section,
   it may be ignored.

5.1.1 Event-Related Fallbacks

Method           Fallback
--------------   -----------------------------------------------------
PUBLISH          Required
REQUEST          PUBLISH
REPLY            Required
ADD              Required
CANCEL           Required
REFRESH          Required
COUNTER          Reply with Not Supported
DECLINECOUNTER   Required if EVENT-COUNTER is implemented; otherwise
                 reply with Not Supported

iCalendar
Property         Fallback
--------------   -----------------------------------------------------
CALSCALE         Ignore; assume GREGORIAN
PRODID           Ignore
METHOD           Required as described in the Method list above
VERSION          Ignore

Silverberg, et. al.         Standards Track                    [Page 97]

RFC 2446                          iTIP                     November 1998

Event-Related
Components       Fallback
--------------   -----------------------------------------------------
VALARM           Reply with Not Supported
VTIMEZONE        Required if any DateTime value refers to a time zone.

Component
Property         Fallback
--------------   -----------------------------------------------------
ATTACH           Ignore
ATTENDEE         Required if EVENT-REQUEST is not implemented;
                 otherwise reply with Not Supported
CATEGORIES       Ignore
CLASS            Ignore
COMMENT          Ignore
COMPLETED        Ignore
nCONTACT          Ignore
CREATED          Ignore
DESCRIPTION      Required
DURATION         Reply with Not Supported
DTSTAMP          Required
DTSTART          Required
DTEND            Required
EXDATE           Ignore
EXRULE           Ignore Reply with Not Supported. If implemented,
                 VTIMEZONE MUST also be implemented.
GEO              Ignore
LAST-MODIFIED    Ignore
LOCATION         Required
ORGANIZER        Ignore
PRIORITY         Ignore
RELATED-TO       Ignore
RDATE            Ignore
RRULE            Ignore. The first instance occurs on the DTStart
                 property. If implemented, VTIMEZONE MUST also be
                 implemented.
RECURRENCE-ID    Required if RRULE is implemented; otherwise Ignore
REQUEST-STATUS   Required
RESOURCES        Ignore
SEQUENCE         Required
STATUS           Ignore
SUMMARY          Ignore
TRANSP           Required if FREEBUSY is implemented; otherwise Ignore
URL              Ignore
UID              Required
X-               Ignore

Silverberg, et. al.         Standards Track                    [Page 98]

RFC 2446                          iTIP                     November 1998

5.1.2 Free/Busy-Related Fallbacks

Method           Fallback
--------------   -----------------------------------------------------
PUBLISH          Implementations MAY ignore the METHOD type. The
                 REQUEST-STATUS "3.14;Unsupported capability" MUST be
                 returned.
REQUEST          Implementations MAY ignore the METHOD type. The
                 REQUEST-STATUS "3.14;Unsupported capability" MUST be
                 returned.
REPLY            Implementations MAY ignore the METHOD type. The
                 REQUEST-STATUS "3.14;Unsupported capability" MUST be
                 returned.

iCalendar
Property         Fallback
--------------   -----------------------------------------------------
CALSCALE         Ignore; assume GREGORIAN.
PRODID           Ignore
METHOD           Required as described in the Method list above.
VERSION          Ignore

Component
Property         Fallback
--------------   -----------------------------------------------------
COMMENT          Ignore
CONTACT          Ignore
DTEND            Required
DTSTAMP          Required
DTSTART          Required
DURATION         Required
FREEBUSY         Required
ORGANIZER        Ignore
REQUEST-STATUS   Ignore
UID              Required
URL              Ignore
X-               Ignore

5.1.3 To-Do-Related Fallbacks

Method           Fallback
--------------   -----------------------------------------------------
PUBLISH          Required
REQUEST          PUBLISH
REPLY            Required
ADD              Required

Silverberg, et. al.         Standards Track                    [Page 99]

RFC 2446                          iTIP                     November 1998

CANCEL           Required
REFRESH          Required
COUNTER          Reply with Not Supported
DECLINECOUNTER   Required if VTODO - COUNTER is implemented; otherwise
                 reply with Not Supported

iCalendar
Property         Fallback
--------------   -----------------------------------------------------
CALSCALE         Ignore; assume GREGORIAN.
PRODID           Ignore
METHOD           Required as described in the Method list above.
VERSION          Ignore

To-Do-Related
Components       Fallback
--------------   -----------------------------------------------------
VALARM           Reply with Not Supported
VTIMEZONE        Required if any DateTime value refers to a time zone.

Component
Property         Fallback
--------------   -----------------------------------------------------
ATTACH           Ignore
ATTENDEE         Required if REQUEST is not implemented; otherwise
                 ignore
CATEGORIES       Ignore
CLASS            Ignore
COMMENT          Ignore
COMPLETED        Required
CONTACT          Ignore
CREATED          Ignore
DESCRIPTION      Required
DUE              Required
DURATION         Ignore Reply with Not Supported
DTSTAMP          Required
DTSTART          Required
EXDATE           Ignore Reply with Not Supported
EXRULE           Ignore Reply with Not Supported. If implemented,
                 VTIMEZONE MUST also be implemented.
LAST-MODIFIED    Ignore
LOCATION         Ignore
ORGANIZER        Ignore
PERCENT-COMPLETE Ignore
PRIORITY         Required
RECURRENCE-ID    Ignore

Silverberg, et. al.         Standards Track                   [Page 100]

RFC 2446                          iTIP                     November 1998

RELATED-TO       Ignore
REQUEST-STATUS   Ignore
RDATE            Ignore
RRULE            Ignore.  The first instance occurs on the DTSTART
                 property. If implemented, VTIMEZONE MUST also be
                 implemented.
RESOURCES        Ignore
SEQUENCE         Required
STATUS           Required
SUMMARY          Ignore
URL              Ignore
UID              Required
X-               Ignore

5.1.4 Journal-Related Fallbacks

Method           Fallback
--------------   -----------------------------------------------------
PUBLISH          Implementations MAY ignore the METHOD type. The
                 REQUEST-STATUS "3.14;Unsupported capability" MUST be
                 returned.
ADD              Implementations MAY ignore the METHOD type. The
                 REQUEST-STATUS "3.14;Unsupported capability" MUST be
                 returned.
CANCEL           Implementations MAY ignore the METHOD type. The
                 REQUEST-STATUS "3.14;Unsupported capability" MUST be
                 returned.

iCalendar
Property         Fallback
--------------   -----------------------------------------------------
CALSCALE         Ignore; assume GREGORIAN.
PRODID           Ignore
METHOD           Required as described in the Method list above.
VERSION          Ignore

Journal-Related
Components       Fallback
--------------   -----------------------------------------------------
VTIMEZONE        Required if any DateTime value refers to a time zone.

Silverberg, et. al.         Standards Track                   [Page 101]

RFC 2446                          iTIP                     November 1998

Component
Property         Fallback
--------------   -----------------------------------------------------
ATTACH           Ignore
ATTENDEE         Required if JOURNAL-REQUEST is implemented; otherwise
                 ignore
CATEGORIES       Ignore
CLASS            Ignore
COMMENT          Ignore
CONTACT          Ignore
CREATED          Ignore
DESCRIPTION      Required
DTSTAMP          Required
DTSTART          Required
EXDATE           Ignore
EXRULE           Ignore Reply with Not Supported. If implemented,
                 VTIMEZONE MUST also be implemented.
LAST-MODIFIED    Ignore
ORGANIZER        Ignore
RECURRENCE-ID    Ignore
RELATED-TO       Ignore
RDATE            Ignore.
RRULE            Ignore. The first instance occurs on the DTSTART
                 property. If implemented, VTIMEZONE MUST also be
                 implemented.
SEQUENCE         Required
STATUS           Ignore
SUMMARY          Required
URL              Ignore
UID              Required
X-               Ignore

5.2 Latency Issues

   With a store-and-forward transport, it is possible for events to
   arrive out of sequence. That is, a "CANCEL" method may be received
   prior to receiving the associated "REQUEST" for the calendar
   component. This section discusses a few of these scenarios.

5.2.1 Cancellation of an Unknown Calendar Component.

   When a "CANCEL" method is received before the original "REQUEST"
   method the calendar will be unable to correlate the "UID" property of
   the cancellation with an existing calendar component. It is suggested
   that messages that can not be correlated that also contain non-zero
   sequence numbers be held and not discarded. Implementations MAY age
   them out if no other messages arrive with the same "UID" property
   value and a lower sequence number.

Silverberg, et. al.         Standards Track                   [Page 102]

RFC 2446                          iTIP                     November 1998

5.2.2 Unexpected Reply from an Unknown Delegate

   When an "Attendee" delegates an item to another CU they MUST send a
   "REPLY" method to the "Organizer" using the "ATTENDEE" properties to
   indicate that the request was delegated and to whom. Hence, it is
   possible for an "Organizer" to receive an "REPLY" from a CU not
   listed as one of the original "Attendees". The resolution is left to
   the implementation but it is expected that the calendaring software
   will either accept the reply or hold it until the related "REPLY"
   method is received from the "Delegator". If the version of the
   "REPLY" method is out of date the "Organizer" SHOULD treat the
   message as a "REFRESH" message and update the delegate with the
   correct version.

5.3 Sequence Number

   Under some conditions, a CUA may receive requests and replies with
   the same "SEQUENCE" property value. The "DTSTAMP" property is
   utilized as a tie-breaker when two items with the same "SEQUENCE"
   property value are evaluated.

6 Security Considerations

   ITIP is an abstract transport protocol which will be bound to a
   real-time transport, a store-and-forward transport, and perhaps other
   transports. The transport protocol will be responsible for providing
   facilities for authentication and encryption using standard Internet
   mechanisms that are mutually understood between the sender and
   receiver.

6.1 Security Threats

6.1.1 Spoofing the "Organizer"

   In iTIP, the "Organizer" (or someone working on the "Organizer's"
   behalf) is the only person authorized to make changes to an existing
   "VEVENT", "VTODO", "VJOURNAL" calendar component and republish it or
   redistribute updates to the "Attendees". An iCalendar object that
   maliciously changes or cancels an existing "VEVENT", "VTODO" or
   "VJOURNAL" calendar component may be constructed by someone other
   than the "Organizer" and republished or sent to the "Attendees".

6.1.2 Spoofing the "Attendee"

   In iTIP, an "Attendee" of a "VEVENT" or "VTODO" calendar component
   (or someone working on the "Attendee's" behalf) is the only person
   authorized to update any parameter associated with their "ATTENDEE"
   property and send it to the "Organizer". An iCalendar object that

Silverberg, et. al.         Standards Track                   [Page 103]

RFC 2446                          iTIP                     November 1998

   maliciously changes the "ATTENDEE" parameters may be constructed by
   someone other than the real "Attendee" and sent to the "Organizer".

6.1.3 Unauthorized Replacement of the Organizer

   There will be circumstances when "Attendees" of an event or to-do
   decide, using out-of-band mechanisms, that the "Organizer" must be
   replaced. When the new "Organizer" sends out the updated "VEVENT" or
   "VTODO" the "Attendee's" CUA will detect that the "Organizer" has
   been changed, but it has no way of knowing whether or not the change
   was mutually agreed upon.

6.1.4 Eavesdropping

   The iCalendar object is constructed with human-readable clear text.
   Any information contained in an iCalendar object may be read and/or
   changed by unauthorized persons while the object is in transit.

6.1.5 Flooding a Calendar

   Implementations MAY provide a means to automatically incorporate
   "REQUEST" methods into a calendar. This presents the opportunity for
   a calendar to be flooded with requests, which effectively block all
   the calendar's free time.

6.1.6     Procedural Alarms

   The "REQUEST" methods for "VEVENT" and "VTODO" calendar components
   MAY contain "VALARM" calendar components. The "VALARM" calendar
   component may be of type "PROCEDURE" and MAY have an attachment
   containing an executable program. Implementations that incorporate
   these types of alarms are subject to any virus or malicious attack
   that may occur as a result of executing the attachment.

6.1.7 Unauthorized REFRESH Requests

   It is possible for an "Organizer" to receive a "REFRESH" request from
   someone who is not an "Attendee" of an event or to-do. Only
   "Attendee's" of an event or to-do are authorized to receive replies
   to "REFRESH" requests. Replying to such requests to anyone who is not
   an "Attendee" may be a security problem.

6.2 Recommendations

   For an application where the information is sensitive or critical and
   the network is subject is subject to a high probability of attack,
   iTIP transactions SHOULD be encrypted. This may be accomplished using
   public key technology, specifically Security Multiparts for MIME

Silverberg, et. al.         Standards Track                   [Page 104]

RFC 2446                          iTIP                     November 1998

   [RFC-1847] in the iTIP transport binding. This helps mitigate the
   threats of spoofing, eavesdropping and malicious changes in transit.

6.2.1 Use of [RFC-1847] to secure iTIP transactions

   iTIP transport bindings MUST provide a mechanism based on Security
   Multiparts for MIME [RFC-1847] to enable authentication of the
   sender's identity, and privacy and integrity of the data being
   transmitted. This allows the receiver of a signed iCalendar object to
   verify the identity of the sender. This sender may then be correlated
   to an "ATTENDEE" property in the iCalendar object. If the correlation
   is made and the sender is authorized to make the requested change or
   update then the operation may proceed. It also allows the message to
   be encrypted to prevent unauthorized reading of the message contents
   in transit. iTIP transport binding documents describe this process in
   detail.

   Implementations MAY provide controls for users to disable this
   capability.

6.2.2 Implementation Controls

   The threat of unauthorized replacement of the "Organizer" SHOULD be
   mitigated by a calendar system that uses this protocol by providing
   controls or alerts that make "Calendar Users" aware of such
   "Organizer" changes and allowing them to decide whether or not the
   request should be honored.

   The threat of flooding a calendar SHOULD be mitigated by a calendar
   system that uses this protocol by providing controls that may be used
   to limit the acceptable sources for iTIP transactions, and perhaps
   the size of messages and volume of traffic, by source.

   The threat of malicious procedural alarms SHOULD be mitigated by a
   calendar system that uses this protocol by providing controls that
   may be used to disallow procedural alarms in iTIP transactions and/or
   remove all alarms from the object before delivery to the recipient.

   The threat of unauthorized "REFRESH" requests SHOULD be mitigated by
   a calendar system that uses this protocol by providing controls or
   alerts that allow "Calendar User" to decide whether or not the
   request should be honored.  An implementation MAY decide to maintain,
   for audit or historical purposes,  "Calendar Users" who were part of
   an attendee list and who were subsequently uninvited.  Similar
   controls or alerts should be provided when a "REFRESH" request is
   received from these "Calendar Users" as well.

Silverberg, et. al.         Standards Track                   [Page 105]

RFC 2446                          iTIP                     November 1998

7 Acknowledgments

   A hearty thanks to the following individuals who have participated in
   the drafting, review and discussion of this memo:

   Anik Ganguly, Dan Hickman, Paul Hill, Daryl Huff, Bruce Kahn, Antoine
   Leca, Bob Mahoney, John Noerenberg, Leo Parker, John Rose, Doug
   Royer, Vinod Seraphin, Richard Shusterman, Derik Stenerson, John Sun,
   Alexander Taler, Kevin Tsurutome.

8 Bibliography

   [iCAL]     Dawson, F. and D. Stenerson, "Internet Calendaring and
              Scheduling Core Object Specification - iCalendar", RFC
              2445, November 1998.

   [iMIP]     Dawson, F., Mansour, S. and S. Silverberg, "iCalendar
              Message-Based Interoperability Protocol - iMIP", RFC 2447,
              November 1998.

   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [US-ASCII] Coded Character Set--7-bit American Standard Code for
              Information Interchange, ANSI X3.4-1986.

Silverberg, et. al.         Standards Track                   [Page 106]

RFC 2446                          iTIP                     November 1998

9 Authors' Addresses

   The following address information is provided in a vCard v3.0,
   Electronic Business Card, format.

   The authors of this memo are:

   BEGIN:VCARD
   VERSION:3.0
   N:Dawson;Frank
   FN:Frank Dawson
   ORG:Lotus Development Corporation
   ADR;WORK;POSTAL;PARCEL:;;6544 Battleford Drive;Raleigh;NC;27613-
    3502;USA
   TEL;TYPE=WORK,MSG:+1-919-676-9515
   TEL;TYPE=WORK,FAX:+1-919-676-9564
   EMAIL;TYPE=PREF,INTERNET:Frank_Dawson@Lotus.com
   EMAIL;TYPE=INTERNET:fdawson@earthlink.net
   URL:http://home.earthlink.net/~fdawson
   END:VCARD

   BEGIN:VCARD
   VERSION:3.0
   N:Hopson;Ross
   FN:Ross Hopson
   ORG:On Technology, Inc.
   ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 1600;434 Fayetteville St.
     Mall\, Two Hannover Square;Raleigh;NC;27601
   TEL;TYPE=WORK,MSG:+1-919-890-4036
   TEL;TYPE=WORK,FAX:+1-919-890-4100
   EMAIL;TYPE=INTERNET:rhopson@on.com
   END:VCARD

   BEGIN:VCARD
   VERSION:3.0
   N:Mansour;Steve
   FN:Steve Mansour
   ORG:Netscape Communications Corporation
   ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain
     View;CA;94043;USA
   TEL;TYPE=WORK,MSG:+1-650-937-2378
   TEL;TYPE=WORK,FAX:+1-650-937-2103
   EMAIL;TYPE=INTERNET:sman@netscape.com
   END:VCARD

Silverberg, et. al.         Standards Track                   [Page 107]

RFC 2446                          iTIP                     November 1998

   BEGIN:VCARD
   VERSION:3.0
   N:Silverberg;Steve
   FN:Steve Silverberg
   ORG:Microsoft Corporation
   ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
   Redmond;WA;98052-6399;USA
   TEL;TYPE=WORK,MSG:+1-425-936-9277
   TEL;TYPE=WORK,FAX:+1-425-936-8019
   EMAIL;INTERNET:stevesil@Microsoft.com
   END:VCARD

   The iCalendar object is a result of the work of the Internet
   Engineering Task Force Calendaring and scheduling Working Group. The
   chairman of that working group is:

   BEGIN:VCARD
   VERSION:3.0
   N:Ganguly;Anik
   FN:Anik Ganguly
   ORG:Open Text Inc.
   ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
    Livonia;MI;48152;USA
   TEL;TYPE=WORK,MSG:+1-734-542-5955
   EMAIL;TYPE=INTERNET:ganguly@acm.org
   END:VCARD

   The co-chairman of that working group is:

   BEGIN:VCARD
   VERSION:3.0
   N:Moskowitz;Robert
   FN:Robert Moskowitz
   NICKNAME:Bob
   EMAIL; TYPE=INTERNET:rgm-ietf@htt-consult.com
   END:VCARD

Silverberg, et. al.         Standards Track                   [Page 108]

RFC 2446                          iTIP                     November 1998

10.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Silverberg, et. al.         Standards Track                   [Page 109]


Network Working Group                                         F. Dawson
Request for Comments: 2447                                        Lotus
Category: Standards Track                                    S. Mansour
                                                               Netscape
                                                          S. Silverberg
                                                              Microsoft
                                                          November 1998

           iCalendar Message-Based Interoperability Protocol
                                 (iMIP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Abstract

   This document, [iMIP], specifies a binding from the iCalendar
   Transport-independent Interoperability Protocol (iTIP) to Internet
   email-based transports. Calendaring entries defined by the iCalendar
   Object Model [iCAL] are composed using constructs from [RFC-822],
   [RFC-2045], [RFC-2046], [RFC-2047], [RFC-2048] and [RFC-2049].

   This document is based on discussions within the Internet Engineering
   Task Force (IETF) Calendaring and Scheduling (CALSCH) working group.
   More information about the IETF CALSCH working group activities can
   be found on the IMC web site at http://www.imc.org, the IETF web site
   at http://www.ietf.org/html.charters/calsch-charter.html. Refer to
   the references within this document for further information on how to
   access these various documents.

Dawson, et. al.             Standards Track                     [Page 1]

RFC 2447                          iMIP                     November 1998

Table of Contents

 1 INTRODUCTION........................................................2
  1.1 RELATED MEMOS ...................................................2
  1.2 FORMATTING CONVENTIONS ..........................................3
  1.3 TERMINOLOGY .....................................................4
 2 MIME MESSAGE FORMAT BINDING.........................................4
  2.1 MIME MEDIA TYPE .................................................4
  2.2 SECURITY ........................................................4
    2.2.1 Authorization ...............................................4
    2.2.2 Authentication ..............................................5
    2.2.3 Confidentiality .............................................5
  2.3 [RFC-822] ADDRESSES .............................................5
  2.4 CONTENT TYPE ....................................................5
  2.5 CONTENT-TRANSFER-ENCODING .......................................6
  2.6 CONTENT-DISPOSITION .............................................6
 3 SECURITY CONSIDERATIONS.............................................7
 4 EXAMPLES............................................................8
  4.1 SINGLE COMPONENT WITH AN ATTACH PROPERTY ........................8
  4.2 USING MULTIPART ALTERNATIVE FOR LOW FIDELITY CLIENTS ............8
  4.3 SINGLE COMPONENT WITH AN ATTACH PROPERTY AND INLINE ATTACHMENT ..9
  4.4 MULTIPLE SIMILAR COMPONENTS ....................................10
  4.5 MULTIPLE MIXED COMPONENTS ......................................11
  4.6 DETAILED COMPONENTS WITH AN ATTACH PROPERTY ....................13
 5 RECOMMENDED PRACTICES..............................................14
  5.1 USE OF CONTENT AND MESSAGE IDS .................................14
 6 BIBLIOGRAPHY.......................................................15
 7 AUTHORS' ADDRESSES.................................................16
 8 FULL COPYRIGHT STATEMENT...........................................18

1 Introduction

   This binding document provides the transport specific information
   necessary convey iCalendar Transport-independent Interoperability
   Protocol (iTIP) over MIME as defined in [RFC-822] and [RFC-2045].

1.1 Related Memos

   Implementers will need to be familiar with several other memos that,
   along with this memo, form a framework for Internet calendaring and
   scheduling standards.

   This document, [iMIP], specifies an Internet email binding for iTIP.

   [iCAL] - specifies a core specification of objects, data types,
   properties and property parameters;

Dawson, et. al.             Standards Track                     [Page 2]

RFC 2447                          iMIP                     November 1998

   [iTIP] - specifies an interoperability protocol for scheduling
   between different implementations;

   This memo does not attempt to repeat the specification of concepts or
   definitions from these other memos. Where possible, references are
   made to the memo that provides for the specification of these
   concepts or definitions.

1.2 Formatting Conventions

   The mechanisms defined in this memo are defined in prose. In order to
   refer to elements of the calendaring and scheduling model, core
   object or interoperability protocol defined in [iCAL] and [iTIP] some
   formatting conventions have been used.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in [RFC-2119].

   Calendaring and scheduling roles are referred to in quoted-strings of
   text with the first character of each word in upper case. For
   example, "Organizer" refers to a role of a "Calendar User" within the
   scheduling protocol defined by [iTIP].

   Calendar components defined by [iCAL] are referred to with
   capitalized, quoted-strings of text. All calendar components start
   with the letter "V". For example, "VEVENT" refers to the event
   calendar component, "VTODO" refers to the to-do calendar component
   and "VJOURNAL" refers to the daily journal calendar component.

   Scheduling methods defined by [iTIP] are referred to with
   capitalized, quoted-strings of text. For example, "REQUEST" refers to
   the method for requesting a scheduling calendar component be created
   or modified, "REPLY" refers to the method a recipient of a request
   uses to update their status with the "Organizer" of the calendar
   component.

   Properties defined by [iCAL] are referred to with capitalized,
   quoted-strings of text, followed by the word "property". For example,
   "ATTENDEE" property refers to the iCalendar property used to convey
   the calendar address of a calendar user.

   Property parameters defined by [iCAL] are referred to with lower
   case, quoted-strings of text, followed by the word "parameter". For
   example, "value" parameter refers to the iCalendar property parameter
   used to override the default data type for a property value.

Dawson, et. al.             Standards Track                     [Page 3]

RFC 2447                          iMIP                     November 1998

1.3 Terminology

   The email terms used in this memo are defined in [RFC-822] and [RFC-
   2045]. The calendaring and scheduling terms used in this memo are
   defined in [iCAL] and [iTIP].

2 MIME Message Format Binding

   This section defines the message binding to the MIME electronic mail
   transport.

   The sections below refer to the "originator" and the "respondent" of
   an iMIP message. Typically, the originator is the "Organizer" of an
   event.  The respondent is an "Attendee" of the event.

   The [RFC-822] "Reply-To" header typically contains the email address
   of the originator or respondent of an event. However, this cannot be
   guaranteed as Mail User Agents (MUA) are not required to enforce iMIP
   semantics.

2.1 MIME Media Type

   A MIME entity containing content information formatted according to
   this document will be referenced as a "text/calendar" content type.
   It is assumed that this content type will be transported through a
   MIME electronic mail transport.

2.2 Security

   This section addresses several aspects of security including
   Authentication, Authorization and Confidentiality. Authentication and
   confidentiality can be achieved using [RFC-1847] that specifies the
   Security Multiparts for MIME. This framework defines new content
   types and subtypes of multipart: signed and encrypted. Each contains
   two body parts: one for the protected data and another for the
   control information necessary to remove the protection.

2.2.1 Authorization

   In [iTIP] messages, only the "Organizer" is authorized to modify or
   cancel calendar entries they organize. That is, spoof@xyz.com is not
   allowed to modify or cancel a meeting that was organized by
   a@example.com. Furthermore, only the respondent has the authorization
   to indicate their status to the "Organizer". That is, the "Organizer"
   must ignore an [iTIP] message from spoof@xyz.com that declines a
   meeting invitation for b@example.com.

Dawson, et. al.             Standards Track                     [Page 4]

RFC 2447                          iMIP                     November 1998

   Implementations of iMIP SHOULD verify the authenticity of the creator
   of an iCalendar object before taking any action. The methods for
   doing this are presented later in this document.

   [RFC-1847] Message flow in iTIP supports someone working on behalf of
   a "Calendar User" through use of the "sent-by" parameter that is
   associated with the "ATTENDEE" and "ORGANIZER" properties. However,
   there is no mechanism to verify whether or not a "Calendar User" has
   authorized someone to work on their behalf. It is left to
   implementations to provide mechanisms for the "Calendar Users" to
   make that decision.

2.2.2 Authentication

   Authentication can be performed using an implementation of [RFC-1847]
   "multipart/signed" that supports public/private key certificates.
   Authentication is possible only on messages that have been signed.
   Authenticating an unsigned message may not be reliable.

2.2.3 Confidentiality

   To ensure confidentiality using iMIP implementations should utilize
   [RFC-1847]-compliant encryption. The protocol does not restrict a
   "Calendar User Agent" (CUA) from forwarding iCalendar objects to
   other users or agents.

2.3 [RFC-822] Addresses

   The calendar address specified within the "ATTENDEE" property in an
   iCalendar object MUST be a fully qualified, [RFC-822] address
   specification for the corresponding "Organizer" or "Attendee" of the
   "VEVENT" or "VTODO".

   Because [iTIP] does not preclude "Attendees" from forwarding
   "VEVENTS" or "VTODOS" to others, the [RFC-822] "Sender" value may not
   equal that of the "Organizer". Additionally, the "Organizer" or
   "Attendee" cannot be reliably inferred by the [RFC-822] "Sender" or
   "Reply-to" values of an iMIP message. The relevant address MUST be
   ascertained by opening the "text/calendar" MIME body part and
   examining the "ATTENDEE" and "ORGANIZER" properties.

2.4 Content Type

   A MIME body part containing content information that conforms to this
   document MUST have an [RFC-2045] "Content-Type" value of
   "text/calendar". The [RFC-2045] "Content-Type" header field must also
   include the type parameter "method". The value MUST be the same as
   the value of the "METHOD" calendar property within the iCalendar

Dawson, et. al.             Standards Track                     [Page 5]

RFC 2447                          iMIP                     November 1998

   object.  This means that a MIME message containing multiple iCalendar
   objects with different method values must be further encapsulated
   with a "multipart/mixed" MIME entity. This will allow each of the
   iCalendar objects to be encapsulated within their own "text/calendar"
   MIME entity.

   A "charset" parameter MUST be present if the iCalendar object
   contains characters that are not part of the US-ASCII character set.
   [RFC-2046] discusses the selection of an appropriate "charset" value.

   The optional "component" parameter defines the iCalendar component
   type contained within the iCalendar object.

   The following is an example of this header field with a value that
   indicates an event message.

        Content-Type:text/calendar; method=request; charset=UTF-8;
              component=vevent

   The "text/calendar" content type allows for the scheduling message
   type to be included in a MIME message with other content information
   (i.e., "multipart/mixed") or included in a MIME message with a
   clear-text, human-readable form of the scheduling message (i.e.,
   "multipart/alternative").

   In order to permit the information in the scheduling message to be
   understood by MIME user agents (UA) that do not support the
   "text/calendar" content type, scheduling messages SHOULD be sent with
   an alternative, human-readable form of the information.

2.5 Content-Transfer-Encoding

   Note that the default character set for iCalendar objects is UTF-8. A
   transfer encoding SHOULD be used for iCalendar objects containing any
   characters that are not part of the US-ASCII character set.

2.6 Content-Disposition

   The handling of a MIME part should be based on its [RFC-2045]
   "Content-Type". However, this is not guaranteed to work in all
   environments. Some environments handle MIME attachments based on
   their file type or extension. To operate correctly in these
   environments, implementations may wish to include a "Content-
   Disposition" property to define a file name.

Dawson, et. al.             Standards Track                     [Page 6]

RFC 2447                          iMIP                     November 1998

3 Security Considerations

   The security threats that applications must address when implementing
   iTIP are detailed in [iTIP]. Two spoofing threats are identified:
   Spoofing the "Organizer", and Spoofing an "Attendee". To address
   these threats, the originator of an iCalendar object must be
   authenticated by a recipient. Once authenticated, a determination can
   be made as to whether or not the originator is authorized to perform
   the requested operation. Compliant applications MUST support signing
   and encrypting text/calendar attachments using a mechanism based on
   Security Multiparts for MIME [RFC-1847] to facilitate the
   authentication the originator of the iCalendar object.
   Implementations MAY provide a means for users to disable signing and
   encrypting. The steps are described below:

   1. The iCalendar object MUST be signed by the "Organizer" sending an
   update or the "Attendee" sending a reply.

   2. Using the [RFC-1847]-compliant security mechanism, determine who
   signed the iCalendar object. This is the "signer". Note that the
   signer is not necessarily the person sending an e-mail message since
   an e-mail message can be forwarded.

   3. Correlate the signer to an "ATTENDEE" property in the iCalendar
   object. If the signer cannot be correlated to an "ATTENDEE" property,
   ignore the message.

   4. Determine whether or not the "ATTENDEE" is authorized to perform
   the operation as defined by [iTIP]. If the conditions are not met,
   ignore the message.

   5. If all the above conditions are met, the message can be processed.

   To address the confidentiality security threats, signed iMIP messages
   SHOULD be encrypted by a mechanism based on Security Multiparts for
   MIME [RFC-1847].

   It is possible to receive iMIP messages sent by someone working on
   behalf of another "Calendar User". This is determined by examining
   the "sent-by" parameter in the relevant "ORGANIZER" or "ATTENDEE"
   property.  [iCAL] and [iTIP] provide no mechanism to verify that a
   "Calendar User" has authorized someone else to work on their behalf.
   To address this security issue, implementations MUST provide
   mechanisms for the "Calendar Users" to make that decision before
   applying changes from someone working on behalf of a "Calendar User".

Dawson, et. al.             Standards Track                     [Page 7]

RFC 2447                          iMIP                     November 1998

4 Examples

4.1 Single Component With An ATTACH Property

   This minimal message shows how an iCalendar object references an
   attachment. The attachment is accessible via its URL.

   From: sman@netscape.com
   To: stevesil@microsoft.com
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding: 7bit

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:sman@netscape.com
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:sman@netscape.com
   ATTENDEE;RSVP=YES:mailto:stevesil@microsoft.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T210000Z
   DTEND:19970701T230000Z
   SUMMARY:Phone Conference
   DESCRIPTION:Please review the attached document.
   UID:calsvr.example.com-873970198738777
   ATTACH:ftp://ftp.bar.com/pub/docs/foo.doc
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.2 Using Multipart Alternative for Low Fidelity Clients

   This example shows how a client can emit a multipart message that
   includes both a plain text version as well as the full iCalendar
   object.  Clients that do not support text/calendar will still be
   capable of rendering the plain text representation.

   From: foo1@example.com
   To: foo2@example.com
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type: multipart/alternative;boundary="01BD3665.3AF0D360"

   --01BD3665.3AF0D360
   Content-Type: text/plain;charset=us-ascii

Dawson, et. al.             Standards Track                     [Page 8]

RFC 2447                          iMIP                     November 1998

   Content-Transfer-Encoding: 7bit

   This is an alternative representation of a TEXT/CALENDAR MIME Object
   When: 7/1/1997 10:00AM PDT - 7/1/97 10:30AM PDT
   Where:
   Organizer: foo1@example.com
   Summary: Phone Conference

   --01BD3665.3AF0D360
   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding: 7bit

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:foo1@example.com
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
   ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T170000Z
   DTEND:19970701T173000Z
   SUMMARY:Phone Conference
   UID:calsvr.example.com-8739701987387771
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   --01BD3665.3AF0D360

4.3 Single Component With An ATTACH Property and Inline Attachment

   This example shows how a message containing an iCalendar object
   references an attached document. The reference is made using a
   Content-id (CID). Thus, the iCalendar object and the document are
   packaged in a multipart/related encapsulation.

   From: foo1@example.com
   To: foo2@example.com
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type: multipart/related; boundary="boundary-example-1";
                 type=text/calendar

   --boundary-example-1

Dawson, et. al.             Standards Track                     [Page 9]

RFC 2447                          iMIP                     November 1998

   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="event.vcs"

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:foo1@example.com
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
   ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T180000Z
   DTEND:19970701T183000Z
   SUMMARY:Phone Conference
   UID:calsvr.example.com-8739701987387771
   ATTACH:cid:123456789@example.com
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   --boundary-example-1
   Content-Type: application/msword; name="FieldReport.doc"
   Content-Transfer-Encoding: base64
   Content-Disposition: inline; filename="FieldReport.doc"
   Content-ID: <123456789@example.com>

   0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAABAAAARAAAAAAA
   AAAAEAAAQAAAAAEAAAD+////AAAAAEUAAAD/////////////////////////////////

   --boundary-example-1--

4.4 Multiple Similar Components

   Multiple iCalendar components of the same type can be included in the
   iCalendar object when the METHOD is the same for each component.

   From: foo1@example.com
   To: foo2@example.com
   Subject: Summer Company Holidays
   Mime-Version: 1.0
   Content-Type:text/calendar; method=PUBLISH; charset=US-ASCII
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="event.vcs"

Dawson, et. al.             Standards Track                    [Page 10]

RFC 2447                          iMIP                     November 1998

   BEGIN:VCALENDAR
   PRODID:-//ACME/DESKTOPCALENDAR//EN
   METHOD:PUBLISH
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:MAILTO:FOO1@EXAMPLE.COM
   DTSTAMP:19970611T150000Z
   DTSTART:19970701T150000Z
   DTEND:19970701T230000Z
   SUMMARY:Company Picnic
   DESCRIPTION:Food and drink will be provided
   UID:CALSVR.EXAMPLE.COM-873970198738777-1
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   BEGIN:VEVENT
   ORGANIZER:MAILTO:FOO1@EXAMPLE.COM
   DTSTAMP:19970611T190000Z
   DTSTART:19970715T150000Z
   DTEND:19970715T230000Z
   SUMMARY:Company Bowling Tournament
   DESCRIPTION:We have 10 lanes reserved
   UID:CALSVR.EXAMPLE.COM-873970198738777-2
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

4.5 Multiple Mixed Components

   Different component types must be encapsulated in separate iCalendar
   objects.

   From: foo1@example.com
   To: foo2@example.com
   Subject: Phone Conference
   Mime-Version: 1.0
   Content-Type:multipart/mixed;boundary="--FEE3790DC7E35189CA67CE2C"

   This is a multi-part message in MIME format.

   ----FEE3790DC7E35189CA67CE2C
   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="event1.vcs"

Dawson, et. al.             Standards Track                    [Page 11]

RFC 2447                          iMIP                     November 1998

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:mailto:foo1@example.com
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
   ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970701T210000Z
   DTEND:19970701T230000Z
   SUMMARY:Phone Conference
   DESCRIPTION:Discuss what happened at the last meeting
   UID:calsvr.example.com-8739701987387772
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   ----FEE3790DC7E35189CA67CE2C
   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII
   Content-Transfer-Encoding:7bit
   Content-Disposition: attachment; filename="todo1.vcs"

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   METHOD:REQUEST
   VERSION:2.0
   BEGIN:VTODO
   DUE:19970701T090000-0700
   ORGANIZER:mailto:foo1@example.com
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:mailto:foo1@example.com
   ATTENDEE;RSVP=YES:mailto:foo2@example.com
   SUMMARY:Phone Conference
   DESCRIPTION:Discuss a new location for the company picnic
   UID:calsvr.example.com-td-8739701987387773
   SEQUENCE:0
   STATUS:NEEDS ACTION
   END:VEVENT
   END:VCALENDAR

   ----FEE3790DC7E35189CA67CE2C

Dawson, et. al.             Standards Track                    [Page 12]

RFC 2447                          iMIP                     November 1998

4.6 Detailed Components With An ATTACH Property

   This example shows the format of a message containing a group meeting
   between three individuals. The multipart/related encapsulation is
   used because the iCalendar object contains an ATTACH property that
   uses a CID to reference the attachment.

   From: foo1@example.com
   MIME-Version: 1.0
   To: foo2@example.com,foo3@example.com
   Subject: REQUEST - Phone Conference
   Content-Type:multipart/related;boundary="--FEE3790DC7E35189CA67CE2C"

   ----FEE3790DC7E35189CA67CE2C
   Content-Type: multipart/alternative;
                 boundary="--00FEE3790DC7E35189CA67CE2C00"

   ----00FEE3790DC7E35189CA67CE2C00
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit

   When: 7/1/1997 10:00PM PDT- 7/1/97 10:30 PM PDT
   Where:
   Organizer: foo1@example.com
   Summary: Let's discuss the attached document

   ----00FEE3790DC7E35189CA67CE2C00

   Content-Type:text/calendar; method=REQUEST; charset=US-ASCII;
                    Component=vevent
   Content-Transfer-Encoding: 7bit
   Content-Disposition: attachment; filename="event.vcs"

   BEGIN:VCALENDAR
   PRODID:-//ACME/DesktopCalendar//EN
   PROFILE:REQUEST
   PROFILE-VERSION:1.0
   VERSION:2.0
   BEGIN:VEVENT
   ORGANIZER:foo1@example.com
   ATTENDEE;ROLE=CHAIR;ATTSTAT=ACCEPTED:foo1@example.com
   ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo2@example.com
   ATTENDEE;RSVP=YES;TYPE=INDIVIDUAL:mailto:foo3@example.com
   DTSTAMP:19970611T190000Z
   DTSTART:19970621T170000Z
   DTEND:199706211T173000Z
   SUMMARY:Let's discuss the attached document
   UID:calsvr.example.com-873970198738777-8aa

Dawson, et. al.             Standards Track                    [Page 13]

RFC 2447                          iMIP                     November 1998

   ATTACH:cid:calsvr.example.com-12345aaa
   SEQUENCE:0
   STATUS:CONFIRMED
   END:VEVENT
   END:VCALENDAR

   ----00FEE3790DC7E35189CA67CE2C00

   ----FEE3790DC7E35189CA67CE2C
   Content-Type: application/msword; name="FieldReport.doc"
   Content-Transfer-Encoding: base64
   Content-Disposition: inline; filename="FieldReport.doc"
   Content-ID: <calsvr.example.com-12345aaa>

   R0lGODdhTAQZAJEAAFVVVd3d3e4AAP///ywAAAAATAQZAAAC/5yPOSLhD6OctNqLs94XqAG
   4kiW5omm6sq27gvH8kzX9o1y+s73/g8MCofEovGITCoxKMbyCR16cNSq9YrNarfcrvdriIH
   5LL5jE6rxc3G+v2cguf0uv2Oz+v38L7/DxgoOKjURnjIIbe3yNjo+AgZWYVIWWl5iZnJY6J.

   ----FEE3790DC7E35189CA67CE2C

5 Recommended Practices

   This section outlines a series of recommended practices when using a
   messaging transport to exchange iCalendar objects.

5.1 Use of Content and Message IDs

   The [iCAL] specification makes frequent use of the URI for data types
   in properties such as "DESCRIPTION", "ATTACH", "CONTACT" and others.
   Two forms of URIs are Message ID (MID) and Content ID (CID). These
   are defined in [RFC-2111]. Although [RFC-2111] allows referencing
   messages or MIME body parts in other MIME entities or stores, it is
   strongly recommended that iMIP implementations include all referenced
   messages and body parts in a single MIME entity. Simply put, if an
   iCalendar object contains CID or MID references to other messages or
   body parts, implementations should ensure that these messages and/or
   body parts are transmitted with the iCalendar object. If they are not
   there is no guarantee that the receiving "CU" will have the access or
   the authorization to view those objects.

Dawson, et. al.             Standards Track                    [Page 14]

RFC 2447                          iMIP                     November 1998

6 Bibliography

   [CHST]     Character Sets, ftp://ftp.isi.edu/in-
              notes/iana/assignments/character-sets

   [iCAL]     Dawson, F. and D. Stenerson, "Internet Calendaring and
              Scheduling Core Object Specification - iCalendar", RFC
              2445, November 1998.

   [iTIP]     Silverberg, S., Mansour, S., Dawson, F. and R. Hopson,
              "iCalendar Transport-Independent Interoperability Protocol
              (iTIP): Scheduling Events, Busy Time, To-dos and Journal
              Entries", RFC 2446, November 1998.

   [RFC-822]  Crocker, D., "Standard for the Format of ARPA Internet
              Text Messages", STD 11, RFC 822, August 1982.

   [RFC-1847] Galvin, J., Murphy, S., Crocker, S. and N. Freed,
              "Security Multiparts for MIME: Multipart/Signed and
              Multipart/Encrypted", RFC 1847, October 1995.

   [RFC-2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) - Part One: Format of Internet Message
              Bodies", RFC 2045, November 1996.

   [RFC-2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) - Part Two: Media Types", RFC 2046,
              November 1996.

   [RFC-2047] Moore, K., "Multipurpose Internet Mail Extensions (MIME) -
              Part Three: Message Header Extensions for Non-ASCII Text",
              RFC 2047, November 1996.

   [RFC-2048] Freed, N., Klensin, J. and J. Postel, "Multipurpose
              Internet Mail Extensions (MIME) - Part Four: Registration
              Procedures", RFC 2048, January 1997.

   [RFC-2111] Levinson, E., "Content-ID and Message-ID Uniform Resource
              Locators", RFC 2111, March 1997.

   [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

Dawson, et. al.             Standards Track                    [Page 15]

RFC 2447                          iMIP                     November 1998

7 Authors' Addresses

   The following address information is provided in a vCard v3.0,
   Electronic Business Card, format.

   BEGIN:VCARD
   VERSION:3.0
   N:Dawson;Frank
   FN:Frank Dawson
   ORG:Lotus Development Corporation
   ADR;TYPE=WORK,POSTAL,PARCEL:;;6544 Battleford
    Drive;Raleigh;NC;27613-3502;USA
   TEL;TYPE=WORK,MSG:+1-919-676-9515
   TEL;TYPE=WORK,FAX:+1-919-676-9564
   EMAIL;TYPE=INTERNET:fdawson@earthlink.net
   URL:http://home.earthlink.net/~fdawson
   END:VCARD

   BEGIN:VCARD
   VERSION:3.0
   N:Mansour;Steve
   FN:Steve Mansour
   ORG:Netscape Communications Corporation
   ADR;TYPE=WORK,POSTAL,PARCEL:;;501 East Middlefield Road;Mountain
    View;CA;94043;USA
   TEL;TYPE=WORK,MSG:+1-650-937-2378
   TEL;TYPE=WORK,FAX:+1-650-937-2103
   EMAIL;TYPE=INTERNET:sman@netscape.com
   END:VCARD

   BEGIN:VCARD
   VERSION:3.0
   N:Silverberg;Steve
   FN:Steve Silverberg
   ORG:Microsoft Corporation
   ADR;TYPE=WORK,POSTAL,PARCEL:;;One Microsoft Way;
    Redmond;WA;98052-6399;USA
   TEL;TYPE=WORK,MSG:+1-425-936-9277
   TEL;TYPE=WORK,FAX:+1-425-936-8019
   EMAIL;TYPE=INTERNET:stevesil@Microsoft.com
   END:VCARD

Dawson, et. al.             Standards Track                    [Page 16]

RFC 2447                          iMIP                     November 1998

   The iCalendar Object is a result of the work of the Internet
   Engineering Task Force Calendaring and scheduling Working Group. The
   chairmen of that working group are:

   BEGIN:VCARD
   VERSION:3.0
   N:Ganguly;Anik
   FN:Anik Ganguly
   ORG:Open Text Inc.
   ADR;TYPE=WORK,POSTAL,PARCEL:;Suite 101;38777 West Six Mile Road;
    Livonia;MI;48152;USA
   TEL;TYPE=WORK,MSG:+1-734-542-5955
   EMAIL;TYPE=INTERNET:ganguly@acm.org
   END:VCARD

   BEGIN:VCARD
   VERSION:3.0
   N:Moskowitz;Robert
   FN:Robert Moskowitz
   EMAIL;TYPE=INTERNET:rgm-ietf@htt-consult.com
   END:VCARD

Dawson, et. al.             Standards Track                    [Page 17]

RFC 2447                          iMIP                     November 1998

8.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Dawson, et. al.             Standards Track                    [Page 18]


Notes on "Format for the Oceanographic and Atmospheric Master Library Tide Constituent Database"

The following notes by David Flater apply to the 2003-06-06 revision of the TCD documentation, "Format for the Oceanographic and Atmospheric Master Library (OAML) Tide Constituent Database" by Jan Depner.

Re: page 24

As should have been obvious from the fact that open_tide_db returns no context to the caller, libtcd is only designed to handle one open database at a time. Prior to the 2003-10-14 patch, XTide was calling open_tide_db repeatedly with no matching calls to close_tide_db, causing a memory leak. One solution would have been just to add the matching calls to close_tide_db. Instead, the patch from Phil Thornton causes libtcd to free the previous database context automatically if a new database is opened and to reuse the "cached" context if it is the same database.

The following notes by David Flater apply to the 2002-09-21 revision of the TCD documentation, "Format for the Oceanographic and Atmospheric Master Library (OAML) Tide Constituent Database" by Jan Depner. All have been incorporated into the 2003-06-06 revision except for the first one regarding the ordering of the constituents.

Re: page 5

Although it is not a requirement of XTide nor of the TCD format, Mr. Depner has requested that the ordering of the existing constituents in TCD files be frozen for the convenience of other applications. New constituents may be appended but existing ones should not be reshuffled.

Re: page 6

Clarification of nulls

Field descriptions include the phrase "or 0" when a value of zero should be interpreted as "null." "Null" means that the field is omitted and/or not applicable, and the application should do the right thing for that case.

  • For timeadd, the "right thing" is to treat the difference as zero anyway.
  • For levelmultiply, the "right thing" is to treat the value as unity (multiply by one, no change).
  • Directions specify 361 as the "null" value. For those fields, zero means zero.
  • Slack offsets (floodbegins, ebbbegins) are broken as documented. See below.

Change to interpretation of slack offsets

Prior to 2003-03-18, zero was used as the "null" value for slack offsets (floodbegins, ebbbegins). Unfortunately, this caused a conflict with subordinate stations that did need to specify zeros for slack offsets.

It is not correct to default slack offsets to zero when they are omitted. Consider an example where max timeadd is 6 hours, min timeadd is 5 hours, and slack offsets are omitted. If the slack offsets are defaulted to zero, the results are nonsense. Instead, the slack offsets must be defaulted to values that are "reasonable" given the skew of the max and min offsets. XTide simply averages the two.

This conflict was resolved in the 2003-03-18 revision of libtcd, tcd-utils, and XTide by changing the "null" value. Omitted slack offsets are now represented with the value NULLSLACKOFFSET defined in libtcd/tcd.h, which is 0xA00 (2560).

"Simplified" type 2 records

Prior to the revisions of 2003-03-27, a simplified representation could be used for type 2 records where the max and min values were identical and there were no slack offsets, current directions, or average levels. In such cases, the max fields were all set to their null values and only the min fields were used. This corresponds to a shorthand notation that is used in the offsets.xml format. It is also analogous to a certain implementation detail in XTide, where a simpler algorithm can be used for simple offsets. However, XTide does its own simplifications and its behavior is not impacted by the choice of representation in the database.

Unfortunately, "simplified" type 2 records also caused a conflict. A station having a nonzero min time offset and a zero max time offset with no other fields being relevant would be mistaken for a simplified case, and the min time offset would incorrectly be used for both max and min. This conflict was resolved in the 2003-03-27 revision of libtcd, tcd-utils, and XTide by doing away with "simplified" type 2 records (which were undocumented to begin with).

Re: page 23

Since "simplified" type 2 records were abolished, the check_simple function documented on page 23 now is used only to determine whether restore_tide_db should output the shorthand form to offsets.xml. The boolean value that it returns (erratum: return documented as void) is only a convenience and does not impact the interpretation of the record any longer.

David Flater
$Id: tcd_notes.html,v 1.11 2003/10/14 18:04:23 flaterco Exp $